«Нельзя войти дважды в одну и ту же реку. Потому что это не та же река, и он не тот же человек» – приписывается Гераклиту
После инцидента сотрудники организации беспокоятся о том, что он может повториться. В некотором смысле, точно такой же инцидент не может повториться, потому что после него организация изменилась. Специалисты по реагированию на инциденты наверняка будут более эффективны в устранении неисправности, с которой они столкнулись недавно, чем с той, с которой они сталкиваются впервые.
Справедливости ради, если база данных снова выйдет из строя, сказать: «Ну, на самом деле, это не тот же инцидент, что в прошлый раз, потому что теперь у нас есть опыт с выходом базы данных из строя, поэтому мы смогли восстановить ее быстрее» — не очень успокаивает организацию. Люди беспокоятся, что существует неминуемый риск, который остался нерешенным, и слова «это не тот же инцидент, что и в прошлый раз» не снимают опасения, что риск не был устранен.
Но я думаю, что люди склонны рассматривать неправильный уровень абстракции, когда они говорят о решении проблем, выявленных в результате последнего инцидента. Они страдают от того, что я называю «синдром никогда-больше»:
Келвин хочет гарантировать, что последний инцидент не повторится
Насыщение — это пример более высокоуровневого паттерна, о котором никогда не говорят, когда речь идет об устранении повторяющихся инцидентов. Я утверждаю, что насыщение — это чрезвычайно распространенный паттерн в инцидентах: я упоминал его, когда писал о публичных отчетах об инцидентах в Canva, Slack, OpenAI, Cloudflare, Uber и Rogers.
Причина, по которой люди не обсуждают паттерн Насыщение, заключается в том, что они, как правило, слишком сосредоточены на конкретных деталях насыщения последнего инцидента.
Но существует много ресурсов, которые могут иссякнуть, и существует много возможных режимов сбоя из-за перегрузки. Могут исчерпаться ресурсы процессоров, памяти, диска, пула потоков, пропускной способности, вы можете достичь пределов скорости, вы даже можете нарушить пределы, о существовании которых вы не знали и которые никогда не отображаются в виде метрик. Удивительно, как много разных вещей может исчерпаться.
Мой личный любимый паттерн — это непредвиденное поведение подсистемы, основной целью которой было повышение надежности. И это одна из причин, по которой я скептически отношусь к акценту на корректирующих действиях при анализе инцидентов.
Но есть и много других паттернов, которые можно выявить. Если вы столкнулись с просроченным сертификатом, вы можете ошибочно решить, что проблема заключается в «просроченном сертификате», но изменение поведения в зависимости от времени является более общим шаблоном для этого режима сбоя. И, конечно же, всегда присутствует «давление на продакшен«.
Если вы сосредоточитесь слишком узко на предотвращении конкретных деталей последнего инцидента, вы не сможете выявить более общие закономерности, которые позволят вам предотвратить инциденты в будущем.
При таком узком подходе все ваши инциденты будут выглядеть либо как повторение предыдущих инцидентов («база данных снова вышла из строя!»), либо как совершенно новый и не связанный с предыдущими инцидентами тип сбоя («мы достигли предела скорости с этим сервисом!»). Не видя более высокоуровневых закономерностей, вы не поймете, насколько эти очень разные на первый взгляд инциденты на самом деле более похожи, чем вы думаете.»
