Более года назад я сменил должность разработчика программного обеспечения (software engineer) на должность инженера по надежности сайта (site reliability engineer) в Honeycomb.io. С тех пор все больше моих постов стало появляться в их блоге, и все меньше здесь. Среди них я могу отметить следующие:
Там также есть пара постов, посвященных разборам реальных кейсов, в том числе один о миграции Kafka и еще один о ряде инцидентов, связанных с масштабированием.
В любом случае, у меня не так много тем для разглагольствования, чтобы вести сразу два блога, так что здесь было небольшое затишье. Впрочем, недавно я выступал с докладом на IRConf (видео).
Я публикую этот выступление здесь, потому что я считаю сказанное своими руководящими принципами, но оно не очень укладывается в формат рабочего блога. Я также хочу воспользоваться этой возможностью, потому что не знаю, сколько выступлений проведу в ближайшие несколько лет. Я решил ограничить количество поездок на конференции из-за экологических соображений: если вы видите меня на конференции, это либо совпало с другими поездками по работе или в отпуск, либо она проводилась достаточно близко, чтобы я мог посетить ее используя как можно меньше загрязняющих окружающую среду средств — и поэтому я хотел бы по-прежнему публиковать некоторые интересные доклады, с которыми я выступаю, когда это возможно.
Доклад
Этот доклад прежде всего посвящена идее, что ошибки не являются объективной истиной. Даже если мы внимательно смотрим на объективные факты, ошибки будут произвольными интерпретациями, которые мы придумываем, конструкциями, которые зависят от нашей точки зрения. Их можно сравнить с созвездиями в ночном небе, которые состоят из настоящих звезд, но их фигуры и значения создаются на основе нашей точки зрения и того, что нам напоминают их формы.
Вдобавок я хочу поразмышлять на тему того, что мы можем сделать, как только примем эту идею, с целью выяснить, какие изменения и преимущества мы можем получить от нашей пост-инцидентной методологии, когда мы к ней приспособимся.
Обычно я подхожу к разбору всякого рода инцидентов с большим энтузиазмом. Большинство мыслей в этом докладе не являются моими оригинальными идеями. Я вычитал их или узнал от более умных, более опытных людей, и собрал вместе после того, как долгое время их переваривал. Кстати, мне казалось, что мое название для этого выступления было достаточно остроумным, но, как я случайно узнал несколько дней назад, это чистой воды перефразировка цитаты из книги, которую я прочитал более 3 лет назад. Так что я не могу должным образом указать авторство всех этих идей, потому что я больше не помню, откуда они взялись, и я очень сожалею об этом.
Для организации "ошибка" исполняет целый ряд функций: защита от затруднительных ситуаций, иллюзия контроля, средство дистанцирования и показатель неудачного расследования.
Цитата, которую я сейчас привел, взята из статьи «Лица, признанные виновными, были уволены»: некоторые наблюдения о пользе ошибки, которая посвящена идее, что даже если ошибки являются произвольными конструкциями, они заключают в себе смысловое содержание и полезны для организаций. В этой статье определяются четыре их функции, которые я немного перефразирую:
Защита от затруднительных ситуаций: концепция ошибки или сбоя — это один из способов для организации оградить себя от ответственности за инцидент. Перекладывая вину на конкретного оператора, мы избегаем необходимости подвергать сомнению устоявшиеся механизмы организации и безопасно переводим стрелки.
Иллюзия контроля: фокусируясь на людях и разрабатывая технологические процессы, мы можем позволить себе сохранять иллюзию того, что мы можем управлять миром, вместо того, чтобы признать, что неблагоприятные события произойдут снова. Это дает нам некоторое ощущения комфорта.
Дистанцирование: как правило, речь идет о поддержании идеи о том, что “здесь это не могло произойти”, либо потому, что мы делаем что-то по-другому, либо потому, что мы разные люди с разными практиками. Это также дает нам ощутимое ощущение комфорта.
Неудачное расследование: наконец, эксперты по безопасности склонны рассматривать концепцию ошибки, особенно человеческой, как признак того, что расследование инцидента закончилось слишком рано. Были и более интересные вещи, которые можно было бы раскопать, но этого не было сделано, потому что человеческая ошибка сама по себе заслуживает разбора в качестве происшествия.
В общем, ошибка полезна как концепция, но для исследователя она особенно полезна скорее в качестве сигнала, который сообщает, когда происходит что-то необычное, нежели в качестве объяснения как такового.
И это заставляет меня задуматься о том, как много разборов инцидентов стремятся быть максимально полными. Мы используем инцидент как возможность, потому что сбой это достаточно крупное и серьезное событие, которое позволяет нам поразмышлять обо всем этом. Но естественная формулировка, которую мы обычно принимаем, сваливает вину в оперативную плоскость.
Здесь я имею в виду не столько обвинения типа “кто-то облажался”, сколько резонный вопрос “что, по нашему мнению, организация должна улучшить” — что, по нашему мнению, нам как команде нужно улучшить в результате нашего разбора. Инцидент и операции являются верхушкой айсберга - они часто нуждаются в улучшении, потому что это действительно сложная работа, выполняемая в особых обстоятельствах, и ее стоит постоянно корректировать. Но ограничиваться на них значило бы пропустить большое количество возможного контента, который мог бы быть полезным.
Люди, выполняющие операции, в той или иной степени оказываются в ситуации, когда многие важные решения уже приняты. Что предстоит тестировать, кто был нанят, каковы бюджеты и все эти факторы в значительной степени определяются остальной частью организации, а они ведь также имеют значение. Они задают контекст, в котором совершаются операции.
Таким образом, вопрос заключается в том, как нам избавиться от этого поверхностного видения и начать выяснять, что происходит ниже этой организационной ватерлинии.
Первый шаг в расследовании почти любого инцидента — определить хронологию событий (timeline). Это что-то, что позволяет нам пройти вспять от инцидента или его разрешения по цепочке предшествующих событий, чтобы найти способы предотвратить повторение подобных ситуаций. Итак, мы начинаем с самого низа, где мы уже наблюдаем катастрофу, и идем оттуда в обратном направлении.
Привычные концептуальные схемы, в рамках которых мы работаем, стремятся оформить в понятия общие паттерны из этой цепочки событий. Мы называем инцидент сбоем или ошибкой. То, что произошло непосредственно перед ним, обычно называют непосредственной причиной, что особенно часто используется в разборе страховых ситуаций: это последнее событие во всей цепочке, которое могло предотвратить сбой. Затем мы продолжаем двигаться назад. Либо в пяти разных направлениях, потому что мы отрабатываем пять “почему”, либо пока мы не остановимся в каком-нибудь достаточно убедительном месте. Если у вас вызывает подозрение механический или программный компонент, вы, скорее всего, укажете на его недостатки. Если вы не очень доверяете людям или даже целым командам, вы можете обнаружить негативное влияния человеческого фактора.
Даже само понятие устойчивого состояния является шатким. Большие системы всегда находятся в каком-то странном состоянии деградации. Одним словом, вы обязательно найдете то, что будете искать. Понятия, которые мы используем, линза, через которую мы смотрим на инцидент, влияют на то, как мы строим наши объяснения.
Однако всю полноту комплексной системы не рассмотреть через какую-нибудь одну конкретную линзу, ведь она представляет целый набор взаимодействий. Чтобы получить более полное комплексное представление, мы должны учитывать то, как все выглядело в динамике в разных промежутках времени, а не ограничиваться нашим ретроспективным видением, когда мы оглядываемся назад. Многое происходит одновременно, множество решений уже принято, чтобы избежать плохих ситуаций, некоторые из которых никогда не происходили, а некоторые уже произошли.
Предвзятость задним числом чем-то похожа на предвзятость результата, которая, по сути, говорит о том, что, поскольку мы знаем, что был сбой, каждое решение, которое мы рассматриваем и которое было принято до инцидента, будет казаться нам рискованным и неправильным. Это потому, что мы уже знаем результат, он влияет на наше суждение. Но когда люди шли по этому пути и решали, что им делать, они старались делать свою работу хорошо; они принимали наилучшие решения в меру своих способностей и информации, доступной в то время.
На самом деле мы не можем избежать предвзятости задним числом, но мы можем учитывать ее. Что мы можем сделать, так это посмотреть, что было доступно в то время, и рассмотреть сигналы, которые были доступны людям. Если они приняли решение, которое выглядит странно, то поищите, что могло сделать его лучше в сравнении с альтернативами того времени.
Контрфактические предположения — это еще одна вещь, которую следует избегать, и которую сложнее всего исключить из разборов инцидентов. По сути, это рассуждения о вещах, которые никогда не происходили и никогда не произойдут. Это о тех случаях, когда мы говорим: “О, если бы мы сделали это в этот момент вместо того, что сделали, то инцидент был бы предотвращен”. Они оперируют в вымышленной вселенной, которой никогда не было, и они непродуктивны.
Я считаю полезным всегда переводить эти комментарии в плоскость будущего: “в следующий раз, когда это произойдет, мы должны попробовать это, чтобы предотвратить проблему”. Это ориентирует дискуссию на более реалистичные средства: как сделать это сценарий более вероятным, а неблагоприятный исключить. Во многих случаях такое предложение даже становится бесполезным: если изменить что-то еще в системе, данный сценарий может больше не вызывать проблем в будущем или может показать, что возможное исправление на самом деле приведет к еще большей путанице.
Наконец, нормативные суждения. Они зачастую очень близки к контрфактическим предположениям, но вы можете отличить их, потому что они, как правило, касаются того, что люди должны или не должны делать, часто в контексте технологических процессов или вопросов компетентности. “Инженер должен был проверить вывод более тщательно, и он не должен был запускать команду, не посоветовавшись с кем-нибудь еще, как указано в регламенте”. Что ж, он так сделал, потому что в тех обстоятельствах это, возможно, выглядело вполне разумно!
Риск контрфактического суждения заключается в том, что оно предполагает, что установленные технологические процессы правильны и реально применимы к рассматриваемой ситуации. Оно предполагает, что отклонения и корректировки, сделанные исполнителем, обречены на неудачу, даже если мы будем игнорировать все случаи, когда они работают. Мы не можем должным образом исправить технологические процессы, если думаем, что они уже совершенны и не следовать им неправильно, и мы не можем улучшить инструментарий, если считаем, что проблема всегда в том, что кто-то неправильно его использует.
Ключевым фактором является понимание того, что в рамках высокой нагруженности реакции на инциденты с неудачным и успешным исходом используют одни и те же механизмы. Мы часто устаем, отвлекаемся или, возможно, брошены туда без надлежащей подготовки. То, что мы делаем для того, чтобы все шло правильно и приносило успешный результат, также играет роль, когда что-то идет не так.
Люди ожидают сигналов, и у них есть опыт и подготовка, которые влияют на принятие трудных решений, которые обычно возникают в разных ситуациях. Мы склонны хотеть, чтобы все шло правильно. Результат имеет тенденцию определять, было ли решение хорошим или нет, но механизм принятия решений является общим как для решений, которые приносят хороший результат, так и для тех, которые оказываются неудачными. И поэтому нам нужно изучать, как эти решения принимаются из лучших побуждений, чтобы иметь шанс улучшить ход событий в следующий раз.
Это приводит к мысли, что нам бы стоило смотреть на то, что не видно, потому что именно здесь можно увидеть настоящую работу.
Я говорю, что это “настоящая работа”, потому что мы подходим к задаче уже с определенным пониманием вещей, своего рода ментальной моделью. Эта ментальная модель представляет собой сведенный опыт, который у нас есть, и позволяет нам структурировать все события, с которыми мы сталкиваемся. Это именно то, что мы используем для предсказания последствий наших решений.
Когда мы разбираемся с инцидентом, там почти всегда есть какой-нибудь сюрприз, а это означает, что сталкиваются мир и наша ментальная модель. Это несоответствие между нашим пониманием мира и реальным миром уже было в нас. Этот разрыв должен быть закрыт. Большие дыры в хронологии событий инцидента, как правило, являются одним из тех мест, где это все и происходит.
Всякий раз, когда кто-то говорит, что “здесь ничего важного не происходит”, это, как правило, именно про места, для которых свойственны активные периоды генерации гипотез, где происходит большая часть ремонта и устранения пробелов.
Именно здесь инцидент может стать очень интересным окном во всю скрытую под водой часть организационного айсберга.
Таким образом, возвращаясь обратно к нашему айсбергу, наблюдая за тем, как принимаются решения в данный момент, вы можете разглядеть скрытые под водой переменные, которые на него повлияли. На что смотрят люди, как они принимают решения. Какова их перспектива. На них влияло все, что происходило раньше.
Если вы видите одновременные сбои или влияние сразу на несколько систем, выясните, с какой из них разбираются первой и почему, вероятно, это даст вам представление о том, в чем уверены исполнители, и что, по их мнению, более важно для организации и пользователей. Таком образом они отражают ценности и приоритеты.
Если вы посмотрите, у кого они просят помощи и где они ищут информацию (если ищут), это позволит вам узнать о различных социальных и других динамиках, которые могут происходить в вашей организации. Это может быть связано с тем, что некоторые люди являются столпами знаний, другие - недотепами, которых считают более или менее компетентными. А также вы можете сделать выводы о том, что люди думают о состоянии документации на данный момент времени.
Вот почему так важно изменить то, как мы смотрим на ошибки и конструируем их. Если мы продолжить применять прямолинейный причинно-следственный подход, мы будем склонны лишь скользить по поверхности. Смотреть на то, как люди выполняют свою работу и как они принимают решения, — это эффективный способ опуститься ниже этой ватерлинии и оказать гораздо более широкое влияние, чем оставаться над водой.
Приглашаем всех желающих на открытое занятие «Web-технологии». Чтобы победить, нужно знать своего врага в лицо! На этом уроке мы познакомимся с основами веб-технологий чтобы нас не пугали такие слова, как HTML CSS FrontEnd и BackEnd. Регистрация по ссылке.
