“Реальные инженерные задачи” – это серия статей, в которых Gergely автор блога “Информационный бюллетень инженера-прагматика” поделится примерами из практики программной инженерии и инженерного менеджмента в технологических компаниях. Возможно, вы узнаете что-то новое из этих статей, поскольку мы погружаемся в содержащиеся в них концепции. Серия состоит из 4 статей, которые мы будем публиковать каждую неделю.
Под сбоем понимается событие, когда система, сервис или приложение, принадлежащее вашей команде или компании, становится недоступной или перестает функционировать в соответствии с ожиданиями. Воздействие сбоя может варьироваться от очень незначительного (то, что замечают немногие пользователи) до критического (когда он затрагивает большинство клиентов). При возникновении сбоя приоритетом номер один всегда является его устранение. После устранения последствий наступает время для более тщательного расследования: анализа инцидента, составления вскрытия и повышения отказоустойчивости системы.
Как инженер, я считаю, что перебои в работе системы никогда не бывают удачными. И всегда дешевле узнать о чужих сбоях, чем учиться на своих собственных. К счастью, многие технологические компании публикуют публичные отчеты после широкомасштабных сбоев. В этой серии статей мы рассмотрим несколько таких обзоров инцидентов с целью извлечь из них уроки. Возможно, некоторые из опубликованных примеров помогут вам сделать свои системы более устойчивыми к сбоям.
Часть 1. Внутренние и публичные отчеты о причинах сбоев
Публичные обзоры инцидентов не является обязательным условием. На самом деле, в большинстве технологических компаний после сбоев, как правило, не проводится публичное вскрытие инцидентов. Это не означает, что внутреннее расследование и последующие действия не проводятся, просто большинство компаний не публикуют этот документ.
Внутренние отчеты пишутся только для использования внутри компании. Это означает, что используемые формулировки могут быть более свободными, конфиденциальные детали могут быть разглашены, а сама версия документа, как правило, является наиболее подробной версией резюме инцидента.
Внутренние вскрытия, как правило, проходят через внутреннюю проверку инцидента. Чем выше последствия сбоя, тем более жесткие вопросы обычно задаются в ходе такого анализа. Цель анализа инцидента – понять, что привело к сбою, внести изменения, чтобы избежать подобных ситуаций, а также зафиксировать и распространить полученные знания в организации.
Вскрытия инцидентов, проводимые только для клиентов, предназначены только для передачи клиентам, а не для распространения среди общественности. Такие отчеты часто помечаются как “частные и конфиденциальные”, что напоминает клиентам о необходимости не распространять информацию публично.
Вскрытия, предназначенные только для клиентов, обычно проходят более строгий контроль, чтобы исключить публикацию конфиденциальной информации. Некоторые компании опускают детали, которыми они не хотят делиться со своими клиентами. Это могут быть детали реализации, которые, по мнению компании, не должны быть известны клиентам. Это могут быть и такие детали, которые, по мнению компании, не должны быть известны клиентам – по крайней мере, не всем клиентам.
Чем прозрачнее культура компании, тем более похожим будет внутреннее вскрытие на вскрытие, предназначенное только для клиентов. В стартапах и небольших компаниях достаточно часто копия внутреннего вскрытия передается непосредственно клиентам, на которых оно повлияло.
Если же речь идет о крупном заказчике услуги, то вполне разумно попросить провести анализ. Часто это называется RCA – анализ первопричины. Например, когда я работал в Uber в команде по платежам, и у одного из наших платежных провайдеров случались сбои, мы запрашивали RCA у этого поставщика.
Публичные вскрытия инциндентов – это вскрытия, опубликованные на сайте вендора/технологической компании. С ними могут ознакомиться все желающие, а не только клиенты. Такие отчеты обычно тщательно редактируются, из них удаляется конфиденциальная информация и жаргонные выражения, чтобы итоговый документ мог быть доступен широкой аудитории. Данный обзор инцидента будут читать следующие группы:
- Заказчики. Самая важная группа: вскрытие инцидента, надеюсь, восстановит их доверие к компании.
- Технари. Публичные вскрытия часто распространяются на технических форумах. Инженеры-программисты, инженеры по надежности сайтов (SRE) и другие люди, работающие в сфере технологий и не являющиеся клиентами компании, будут читать этот документ с целью извлечь уроки из ошибок компании. Косвенным образом компания, регулярно публикующая качественные обзоры инцидентов, может привлечь технических специалистов, интересующихся вопросами надежности.
- Нетехнические люди. Поскольку постмортем находится в публичной плоскости, его могут прочитать все остальные: инвесторы, регуляторы и другие заинтересованные лица.
- Пресса. Технические издания часто анализируют такие публичные вскрытия. Чем известнее компания, тем больше публикаций посвящено тому, что стало причиной сбоя и какие изменения были внесены в результате.
Написание публичного отчета требует больших усилий, поэтому обычно это стоит делать только в тех случаях, когда это оправдано: либо в случае масштабных сбоев – как способ общения со всеми клиентами, либо в случае сбоев с интересными выводами – как способ распространить эти знания среди технологического сообщества и, возможно, помочь в будущем при найме сотрудников.
В последующих статьях мы посмотрим на некоторые недавние публичные обзоры инцидентов с интересными выводами.
Через неделю. Adevinta: загадка падения DNS. Недетерминированный сбой постоянно ускользает от попыток определить его причину. Когда у вас нет идей, что могло пойти не так, обычно это проблема с кэшированием или DNS (служба доменных имен). Так что же это было – DNS? Кэширование? Или и то, и другое?
