Протокол-11: как применить хаос-инжиниринг для организационных процессов

Наверняка многие слышали про хаос-инжиниринг – сравнительно новый подход к созданию отказоустойчивых систем, основанный на использовании управляемого хаоса. Более точное определение — это подход, предусматривающий проведение экспериментов над production-системой, чтобы убедиться в ее способности выдерживать различные помехи, возникающие во время работы. Этот подход позволяет не просто согласовать системы, устойчивые к мыслимым угрозам, но и выявлять комбинации событий, которые разработчики системы далее не могли себе представить, и сделать систему устойчивой и к такого рода событиям. Наверное самая известная история о применении хаос-инжиниринга – Netflix chaos monkey, созданная Netflix система программных агентов, действующих в их системе, которая случайным образом намеренно нарушает работу системы: удаляет файлы, останавливает процессы или отключает устройств и т.д. Наличие такого агента в системе вынуждает разработчиков встраивать защиту от такого рода происшествий, делая систему очень устойчивой. К тому же этот позволяет выявить проблемы, которых никто не мог предположить, но имеющие критическое влияние на систему. При этом, конечно, всякое действие этой Сhaos monkey тщательно протоколируется и есть возможность автоматически откатить чистоту к работоспособному состоянию, так что когда случайность создаёт такую комбинацию сбоев, к которому система отказывается не готова, работоспособность системы быстро восстанавливается, а разработчики получают информацию, необходимую чтобы устроить в систему защиту и от таких комбинаций.

Как применить этот подход к дизайну организационных процессов? Ответ на этот вопрос, регулярно всплывавший у меня в голове в течение пары лет, пришёл мне во сне. Представьте, вы утром собираетесь на работу, и вы уже готовы выйти из дома, как вам приходит сообщение от вашей компании: “ВНИМАНИЕ! Протокол 11 активирован с 9:00 до 23:00 сего дня”. Вы знаете, что на это время все ваши учётные записи на работе: вход в систему, электронная почта, и даже пропуск в офис компании буду заблокированы. Что система уже автоматически разослала тем, что указан как ваш заместитель для “Протокола 11” написанные вами же инструкции о том, какие задачи вы регулярно делаете, вместе с доступом к вашим рабочим файлам и вашему бэклогу, где описаны все ваши задачи. Вы чувствуете лёгкую тревогу. Хватит ли им информации, чтобы завершить начатое вами? Смогут ли они понять вашу инструкцию и сделать всё как требуется? Завтра вы это узнаете, а сегодня у вас дополнительный оплачиваемый выходной, одновременно с тревогой вы чувствуете радость от предвкушения того, как проведёте этот день. Если что-то пойдёт не так вам, конечно, позвонят, и ваш руководитель сможет в один клик снова сделать доступными и ваши учётные данные, и проход в офис, но вы почти уверенны, что всё пройдёт хорошо. В конце концов вы к этому готовились, и такие ситуации в вашей компании происходят регулярно: автоматизированная система случайным образом определяет, когда и для кого из сотрудников активируется “Протокол 11” и запускает его автоматически.

Казалось бы, зачем такие сложности? Какие выгоды это приносит организации? Первая, и самая очевидная выгода – это позволит сделать организацию устойчивой к внезапному отсутствию сотрудников. Это снижает риски нарушения работы компании, и, к тому же, позволяет в безопасных условиях выявить сотрудников, чьё отсутствие создаёт наиболее высокие из таких рисков. Чтобы проиллюстрировать это, приведу историю, которой поделился со мной один коллега (все события в этой истории вымышленные, любые совпадения являются случайностью). В большой корпорации совет директоров на каждой встрече смотрел на большой дашборд с ключевыми показателями всей корпорации. Как-то утром на очередном собрании директора смотрят на дашборд – а там пусто! То есть часть данных там есть, но одного очень важного показателя нет. Что случилось?! Когда происшествие случается на таком уровне, конечно, поднимают на уши весь ИТ-блок, требуя срочно разобраться, что стало с так любимым всеми отчётом. Примерно через полдня расследований на всех уровнях (организация большая) приходит ответ из одного из ИТ подразделений: у нас заболела шина данных. Разве такое возможно? Оказалось, что в базу данных, откуда брались цифры в дашборд информация поступала так: в одном из многочисленных офисов работала дама, которая каждое утро начинала свой день с того, что включала свои два компьютера, в одном из них открывала учётную систему, из отчёта брала цифры, и вводила его в специальную форму на втором. И вот именно в этот день она внезапно заболела, но никого не успела предупредить, а так как остальные уже и забыли, как работает эта “шина данных”, никому и в голову не пришло что-то по этому поводу предпринять, пока не случился тот самый инцидент на совете директоров. Ещё полдня потребовалось на то, чтобы узнать, откуда именно и куда она переносила данные, так что на следующий день совет директоров таки получил свой дашборд.

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

Вторая выгода –  это подталкивает к радикальной прозрачности, которая является основанием для любого эмпирического процесса. Для того, чтобы можно было подхватить мои задачи в случае внезапного отсутствия необходима не только информация о том, что я обычно делаю, но и о том, что сейчас в процессе выполнения, какова степень готовности у каждой из задач в работе, и каковы были мои намерения относительно дальнейших действий. То есть становится необходимым документировать не только процесс работы и текущее состояние этого процесса, но и намерения, а так же критерии принятия решений, важные для продолжения моей работы. Кроме того, описывая задачу и свои намерения столь явно, чтобы другие могли, оттолкнувшись это этого, реализовать ваши намерения, вы обретёте и сами большую ясность в том, что, почему и зачем вы намерены делать.

Всё это сокращает объём интеллектуальной тёмной материи (ИТМ). ИТМ – термин, введённый Сэмо Бурья для обозначения знаний, критически важных для функционирования и возможности корректировки социальной технологии, но являющихся неявными или даже утерянных. В последнем случае социальная технология (например, наша организация)  может достаточно долгое время успешно функционировать, если внешние условия стабильны, но при их изменении не имея доступа к ИТМ адаптация к новым условиям оказывается невозможной, и система либо перестаёт работать, либо её приходится изобретать заново.

Безусловно такая система потребует существенных усилий со стороны сотрудников и инвестиций в необходимую инфраструктуру, поэтому развёртывание “Протокола 11” на всю организацию будет, скорее всего нецелесообразным. Но применение такого подхода в критических для бизнеса частях организации позволит сделать их более устойчивыми и снизить риски нарушения работы ключевых частей организации. И далее если вы не увидите возможности или целесообразности в развертывании такой системы в организации, этап идея полезна для понимания того, на сколько прозрачно организована ваша работа. Проведя такой мысленный эксперимент, то есть представив себе, как бы сработал “Протокол 11” в вашем случае, вы увидите где в вашей работе или работе вашей команды не хвататет прозрачности в целях, задачах или намерениях.