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

Завершим неделю историей CrowdStrike – о том, как ошибка в обновлении привела к массовому сбою и что компания решила изменить после него.

🔍 РАЗБОР РЕАЛЬНОГО БИЗНЕС-КЕЙСА
CrowdStrike: обновление прошло проверки, но привело к массовому сбою

19 июля 2024 года CrowdStrike выпустила очередное обновление правил для Falcon – программы, которая защищает компьютеры от угроз. После обновления компьютеры на Windows начали аварийно завершать работу. По оценке Microsoft, сбой затронул около 8,5 млн устройств.

Выясняя причину, CrowdStrike обнаружила пробел в тестировании.
Новая конфигурация задействовала вариант обработки данных, который не проверяли в тестах: программа пыталась прочитать значение, отсутствовавшее в переданном наборе данных. Поэтому обновление смогло пройти проверки, хотя при работе на компьютерах клиентов вызывало сбой.

♻️ Чтобы снизить риск повторения, требовалось пересмотреть и проверки, и сам порядок выпуска обновлений.

В разборе от 6 августа 2024 года CrowdStrike описала меры по обоим направлениям. Часть из них к этому времени уже действовала, другие компания ещё планировала или начинала внедрять.

📈 Среди предложенных мер было поэтапное распространение обновлений. Сначала новую версию получает небольшая группа пользователей. Команда наблюдает за тем, как программа работает после обновления, и только затем расширяет внедрение. Так команда получает возможность заметить проблему на небольшом числе устройств и приостановить дальнейшее распространение обновления.

🗒 Для руководителя здесь возникает вопрос, который касается не только программного обеспечения. Проверки могут подтвердить готовность новой системы или нового порядка работы.

Но как организация ограничит последствия ошибки, если проверка всё же её не выявит? Ответ требует трёх решений ещё до начала внедрения.

1️⃣ Определите, с какого масштаба начать.
Выберите подразделение, площадку или группу клиентов, где новые правила можно проверить в условиях, близких к обычной работе. До запуска договоритесь, сколько продлится наблюдение, какие данные нужны для решения о расширении и кто их представит.

2️⃣ Закрепите право приостановить внедрение.
Заранее назовите признаки, при которых внедрение приостанавливают, и человека, который может принять это решение без дополнительного согласования с вышестоящим руководителем. Остановка дальнейшего внедрения не восстановит работу тех, кого сбой уже затронул, поэтому план помощи им нужен заранее.

3️⃣ Проверьте, за счёт чего получен первый результат.
Перед расширением выясните, не приходилось ли руководителю ежедневно вмешиваться в работу, а сотрудникам – обходить установленный порядок, чтобы выполнить задачу. Отчёт должен показывать эти действия, время затраченное на восстановление и нерешённые проблемы. Эти сведения нужны, чтобы оценить, каких усилий потребует внедрение в остальных подразделениях.

⚡️ При следующем внедрении проверьте себя по этим пунктам.

#разбор_реальных_бизнес_кейсов