Говоря об ошибках, Рой Рапопорт из Netflix замечает: «Что доклад 2014 State of DevOps Report доказал мне, так это то, что высокоэффективные DevOps-организации совершают ошибки чаще. Это не только нормально, это как раз то, что компаниям и нужно! Если высокоэффективные компании работают в 30 раз быстрее и при этом уровень сбоев в два раза ниже, очевидно же, что общее число сбоев там выше».
Далее он продолжает: «Я как-то говорил с одним коллегой о недавнем масштабном сбое у нас в Netflix, он произошел, честно говоря, из-за глупейшей ошибки. На самом деле сбой случился из-за одного инженера, за последние 18 месяцев уже дважды полностью выводившего Netflix из строя. Но, конечно, мы его ни за что не уволили бы. За те же 18 месяцев этот инженер продвинул уровень наших эксплуатации и автоматизации вперед не на километры, а на световые годы. Его работа позволила нам безопасно делать развертывания каждый день, и он сам лично провел огромное число развертываний кода».
Рапопорт заключает: «В DevOps должно быть место для таких инноваций и для вытекающего из них риска ошибок. Да, в эксплуатации у вас будет больше сбоев. Но это хорошо, за это нельзя наказывать».
Устраивайте намеренные сбои, чтобы укрепить адаптивность и улучшить обучение
Как мы видели во введении к этой главе, намеренное создание неполадок в среде эксплуатации (например, с помощью Chaos Monkey) — один из способов укрепления адаптивности к сбоям. В этой части мы опишем процессы симуляции и введения сбоев в систему, чтобы удостовериться, что наши системы спроектированы и выстроены правильно, а неполадки контролируемы и происходят, как запланировано. Для этого мы регулярно (или даже непрерывно) будем проводить тесты, чтобы убедиться: системы выходят из строя плавно и предсказуемо.
Как пишет Майкл Нейгард, автор книги Release It! Design and Deploy Production-Ready Software[148], «Подобно тому как в машины встраивают зоны смятия, чтобы при аварии пассажиры оставались в безопасности, вы можете определить, какие элементы системы важнее всего, и спроектировать режимы отказа, способные держать трещины подальше от этих элементов. Если вы специально не определяете режимы отказа, то результат будет непредсказуемым — и, как правило, опасным».
Адаптивность требует, чтобы мы сначала продумали режимы отказа и затем протестировали, работают ли они так, как нам нужно. Один из способов проделать это — специально создавать сбои в эксплуатационной среде и репетировать масштабные аварии, чтобы убедиться, что мы можем быстро восстановиться после инцидентов, когда они на самом деле произойдут, в идеале — так, чтобы клиенты этого не заметили.