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

Приложение Morgue было разработано для того, чтобы команде было легко фиксировать:

• возникла ли проблема из-за запланированного или незапланированного инцидента;

• кто ответствен за разбор ошибок;

• важные логи IRC-чата (особенно важно для проблем, возникших в три часа ночи, когда точное фиксирование деталей может не произойти);

• важные тикеты JIRA для корректирующих действий и дедлайны по ним (эта информация особенно важна для менеджмента);

• ссылки на форумные посты клиентов (где клиенты жалуются на проблемы).

После разработки и использования Morgue число фиксируемых разборов в Etsy сильно увеличилось по сравнению с тем временем, когда они использовали страницы специальной вики, особенно для инцидентов P2, P3 и P4 (то есть инцидентов с низким уровнем серьезности). Этот результат подтвердил гипотезу, что если документировать разбор ошибок с помощью инструментов типа Morgue станет проще, то больше специалистов начнут записывать и детализировать результаты совещаний, и накопленный опыт организации увеличится.

Эми Эдмондсон, профессор управления и менеджмента Гарвардской школы бизнеса и соавтор книги Building the Future: Big Teaming for Audacious Innovation, пишет:

Путь решения проблемы, не обязательно требующий больших затрат времени и денег, — избавиться от предрассудков в отношении ошибок. Эли Лилли делает это еще с ранних 1990-х: она устраивает «вечеринки неудачников», чтобы отметить умные, высококачественные научные эксперименты, закончившиеся неудачей. Эти вечеринки обходятся недорого, а перераспределение ценных ресурсов — а именно ученых — на новые проекты раньше, чем обычно, может сэкономить сотни тысяч долларов, не говоря уже о возможных стимулах для новых открытий.

Когда организации учатся эффективно диагностировать и решать проблемы, то, чтобы не останавливаться в развитии, они неизбежно расширяют понятие того, что считать проблемой. Для этого нужно научиться усиливать слабые сигналы о возможных неполадках. Например, как было описано в части IV, к тому моменту, когда компания Alcoa смогла существенно сократить количество несчастных случаев на производстве, Пол О’Нил, CEO [147]Alcoa, начал получать отчеты не только о реально произошедших несчастных случаях, но и о потенциально аварийных ситуациях.

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

Когда мы работаем в сложных системах, необходимость усиливать слабые сигналы очень важна, чтобы избежать катастрофических последствий. Прекрасный пример — как NASA использовала сигналы о неполадках в эпоху космических шаттлов. В 2003 г., на шестнадцатый день полета космического шаттла Columbia, он взорвался при входе в атмосферу. Сейчас известно, что это произошло из-за того, что во время взлета от внешнего топливного бака оторвался кусок теплоизоляционной пены.

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

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

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

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

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

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