Книга: Руководство по DevOps
Опасность процесса согласования изменений
Опасность процесса согласования изменений
Провал компании Knight Capital — одна из самых показательных ошибок внедрения ПО в недалеком прошлом. Пятнадцатиминутная ошибка развертывания — причем инженеры не могли отключить рабочие сервисы — привела к потере 440 миллионов долларов. Финансовые убытки поставили под удар функционирование организации, в результате чего владельцы были вынуждены быстро продать компанию, чтобы она могла продолжать деятельность без риска для финансовой системы.
Джон Оллспоу замечает, что, когда происходят такие резонансные провалы, как ошибка развертывания Knight Capital, обычно есть две противоречащие фактам интерпретации, почему же эти сбои вообще могли случиться[135].
Первая интерпретация гласит, что авария произошла из-за сбоя в системе контроля изменений. Звучит правдоподобно, поскольку мы можем представить ситуацию, когда лучшие методики контроля могли бы отследить такой риск раньше и не допустили бы отправки изменений в производственную среду. А если бы они и не смогли предотвратить развертывание плохого кода, то мы быстрее обнаружили бы ошибку и сразу же предприняли шаги по восстановлению системы.
Вторая интерпретация заключается в том, что провал случился по вине сбоя тестирования. Это тоже кажется правдоподобным. Чем лучше методы тестирования, тем больше шансы отследить неполадки в самом начале и отменить рискованное развертывание. Или как минимум мы могли бы быстрее заметить ошибку и вернуть систему в рабочее состояние.
Удивительно, но факт: в компаниях с низким уровнем доверия и культурой, основанной на контроле и управлении, частый результат жесткого контроля над изменениями и тестированием — высокая вероятность того, что такие проблемы повторятся снова, с еще более печальным исходом.
Джин Ким (соавтор этой книги) называет осознание того, что контроль над изменениями и тестирование могут иметь совершенно противоположный результат, «одним из важнейших моментов моей профессиональной карьеры. Это озарение было результатом одного разговора в 2013 г. с Джоном Оллспоу и Джезом Хамблом о провале Knight Capital. Я начал сомневаться в некоторых своих основополагающих убеждениях, сформированных за последние десять лет, особенно если учесть мое аудиторское образование».
Ким продолжает: «Как бы печально это ни было, этот момент был для меня ключевым. Они не только убедили меня в том, что они правы, но мы также протестировали эти предположения в обзоре 2014 State of DevOps Reports, что привело ко многим потрясающим открытиям. Построение культуры с высоким уровнем доверия — наверное, самый большой вызов для менеджмента в этом десятилетии».
- Опасность процесса согласования изменений
- Потенциальные опасности чрезмерного контроля над изменениями
- Производительность в IT
- Рецензии коллег vs Получение разрешений
- Обеспечьте условия для координации и планирования изменений
- Введите практику рецензирования изменений
- Практический пример
- Потенциальные опасности тестирования преимущественно вручную и заморозки изменений
- Введите практику парного программирования, чтобы улучшить качество изменений
- Практический пример
- Замена неэффективного рецензирования кода парным программированием в организации Pivotal Labs (2011 г.)
- Оценка эффективности pull request процессов[139]
- Бесстрашно избавляйтесь от бюрократических процессов
- Заключение
- Заключение части IV
- Обеспечьте условия для координации и планирования изменений
- Сущность процесса миграции
- V Совершенствование процесса
- Надежность и безопасность
- Использование сервера Yaffil внутри процесса
- Интегрированная безопасность (NT Integrated Security)
- Безопасность временных таблиц
- Безопасность внешних таблиц. Параметр EXTERNAL FILE DIRECTORY
- Глава 10 Информационная безопасность бизнеса
- 4. Стадии бизнес-процесса взаимодействия с клиентами
- 2.2.2.2 Состояния процесса
- 1.2 Процесс, контекст процесса и потоки