Джин Ким - Руководство по DevOps

Майкл Роберто, Ричард Бомер и Эми Эдмондсон в статье 2006 г. для Harvard Business Review писали, что культура NASA стала одной из причин катастрофы. Они описывали две типичные структуры организаций: стандартизированная модель , где всем управляют установившиеся практики и системы и где жестко соблюдают сроки и бюджеты, и экспериментальная модель , где каждый день каждую задачу и каждую крупицу новой информации оценивают и обсуждают в атмосфере, напоминающей научно-исследовательскую и конструкторскую (R&D) лабораторию.

Они также отмечают: «Фирмы сами навлекают на себя неприятности, принимая неправильный образ мышления, диктующий, как реагировать на неоднозначные угрозы или, в терминах этой книги, на слабые сигналы о неполадках … К 1970 г. NASA создала культуру с жесткой стандартизацией, рекламируя Конгрессу шаттлы как дешевый и многоразовый космический корабль». Вместо экспериментальной модели, где каждый факт должен был оцениваться без предвзятости, в NASA предпочитали четкое следование процедурам. Отсутствие непрерывного обучения и экспериментирования привело к катастрофическим последствиям. Авторы резюмируют: важны именно культура и образ мыслей, а не просто «необходимость быть осторожным», «бдительность сама по себе не может помешать неоднозначным слабым сигналам о неполадках перерасти в дорогостоящие (а иногда и трагичные) ошибки».

Работа в технологическом потоке ценности, например связанном с космическими технологиями, должна восприниматься как принципиально экспериментальное занятие, и управляться она должна соответственно. Вся сделанная работа — это новая потенциально важная гипотеза и источник данных, а не рутинное воспроизведение и подтверждение прежних методов. Вместо того чтобы считать технологическую работу полностью стандартизованной, когда все стремятся к слепому следованию установленным процедурам, нужно постоянно выявлять все более слабые сигналы о возможных сбоях, чтобы лучше понять системы и управлять ими.

Руководители компаний, сознательно или нет, своими действиями укрепляют организационную культуру и ее ценности. Эксперты по аудиту, бухгалтерскому учету и этике давно заметили, что взгляды «верхушки» предопределяют вероятность мошенничества или других недобросовестных действий. Чтобы укрепить культуру обучения и взвешенных рисков, руководители должны постоянно следить, чтобы сотрудники не боялись ошибок, но в то же время чувствовали себя ответственными за их исправление и за получение нового опыта.

Говоря об ошибках, Рой Рапопорт из Netflix замечает: «Что доклад 2014 State of DevOps Report доказал мне, так это то, что высокоэффективные DevOps-организации совершают ошибки чаще. Это не только нормально, это как раз то, что компаниям и нужно! Если высокоэффективные компании работают в 30 раз быстрее и при этом уровень сбоев в два раза ниже, очевидно же, что общее число сбоев там выше».

Далее он продолжает: «Я как-то говорил с одним коллегой о недавнем масштабном сбое у нас в Netflix, он произошел, честно говоря, из-за глупейшей ошибки. На самом деле сбой случился из-за одного инженера, за последние 18 месяцев уже дважды полностью выводившего Netflix из строя. Но, конечно, мы его ни за что не уволили бы. За те же 18 месяцев этот инженер продвинул уровень наших эксплуатации и автоматизации вперед не на километры, а на световые годы. Его работа позволила нам безопасно делать развертывания каждый день, и он сам лично провел огромное число развертываний кода».

Рапопорт заключает: «В DevOps должно быть место для таких инноваций и для вытекающего из них риска ошибок. Да, в эксплуатации у вас будет больше сбоев. Но это хорошо, за это нельзя наказывать».

Как мы видели во введении к этой главе, намеренное создание неполадок в среде эксплуатации (например, с помощью Chaos Monkey) — один из способов укрепления адаптивности к сбоям. В этой части мы опишем процессы симуляции и введения сбоев в систему, чтобы удостовериться, что наши системы спроектированы и выстроены правильно, а неполадки контролируемы и происходят, как запланировано. Для этого мы регулярно (или даже непрерывно) будем проводить тесты, чтобы убедиться: системы выходят из строя плавно и предсказуемо.

Как пишет Майкл Нейгард, автор книги Release It! Design and Deploy Production-Ready Software [148], «Подобно тому как в машины встраивают зоны смятия, чтобы при аварии пассажиры оставались в безопасности, вы можете определить, какие элементы системы важнее всего, и спроектировать режимы отказа, способные держать трещины подальше от этих элементов. Если вы специально не определяете режимы отказа, то результат будет непредсказуемым — и, как правило, опасным».