«В прошлый раз это сработало» — но 68% отключений можно было избежать. Исправьте это сейчас.

Я видел одну и ту же картину снова и снова. Система выходит из строя, команда устраняет видимую проблему, обслуживание возобновляется, и все двигаются дальше. Затем тот же сбой возвращается. Иногда кажется меньше. Иногда это бьет сильнее. Это реальная проблема, стоящая за повторяющимися отключениями электроэнергии. Сломанная часть представляет собой всего лишь одну деталь. Более глубокая проблема заключается в том, что основная причина никогда не устраняется полностью. Я усвоил это на собственном горьком опыте, поддерживая небольшой интернет-магазин. Их сайт продолжал давать сбои в периоды загруженности заказами. Первый инцидент выглядел просто: конфликт плагинов. Команда удалила его, сайт снова загрузился, и работа была завершена. Несколько недель спустя проверка не удалась в другом месте. Влияние пользователя было таким же. Причина изменилась, а слабый процесс — нет. Именно поэтому я не рассматриваю отключение электроэнергии как отдельное событие. Я воспринимаю это как сигнал. То, что я проверяю после каждого сбоя, я начинаю с воздействия на пользователя. Что перестало работать? Кто почувствовал это первым? Было ли это оформление заказа, вход в систему, электронная почта, оплата или внутренние инструменты? Затем я прослеживаю цепочку неудач. Я просматриваю журналы, оповещения, загрузку сервера, состояние сети, последние изменения и любые действия, предпринятые вручную до сбоя. Быстрое исправление может восстановить обслуживание, но оно также может скрыть реальную неисправность. Я задаю три простых вопроса: Что не удалось? Почему это не удалось? Что может привести к повторному провалу? Эта часть имеет наибольшее значение. Если я не могу ответить на последний вопрос, я не чувствую себя готовым. Что я меняю после того, как нахожу причину, я не останавливаюсь на устранении симптома. Если на сервере закончилась память, я проверяю, не вырос ли трафик, не произошла ли утечка ресурсов из-за скрипта или не слишком ли низкий порог оповещения. Если на этапе оплаты произошел сбой, я проверяю вызов службы, настройку тайм-аута и логику повторной попытки. Если сбой произошел из-за плохого обновления, я затягиваю процесс выпуска и тестирую путь отката. Настоящее исправление должно уменьшить вероятность повторения. Быстрый патч только уменьшает панику. Я также описываю этот инцидент простым языком. Не для картотеки. Для следующего человека, которому придется действовать быстро. Мой основной список проверки сбоев. Я делаю список коротким, чтобы его можно было использовать: Определите первый видимый симптом. Проверьте изменение, произошедшее до сбоя. Просмотрите журналы и оповещения из этого окна. Найдите слабое место, а не только сломанную деталь. Назначьте одного владельца для последующих работ. Проверьте путь исправления, прежде чем закрывать дело. Этот список намеренно прост. Когда команда находится под давлением, следует предпринять простые шаги. Что я проверяю, прежде чем снова доверять системе. Я никогда не доверяю восстановлению только потому, что экран выглядит нормально. Я проверяю путь, который не удался. Я проверяю путь резервного копирования. Я проверяю оповещение. Я проверяю передачу управления между людьми и системами. Резервная копия, которая никогда не тестировалась, — это всего лишь обещание. Монитор, который предупреждает слишком поздно, — это всего лишь шум. Передача без четкого владельца – это брешь, которая ждет своего открытия. Однажды я видел, как магазин добавил резервную страницу оформления заказа после проблемы с оплатой. В обзоре все выглядело хорошо. Первое настоящее испытание произошло во время ажиотажа продаж, и резервная страница указывала на тот же сломанный шлюз. У команды было резервное имя, а не резервная функция. Эта ошибка стоила им еще одного отключения электроэнергии. Что больше всего помогает в повседневной работе: я сохраняю спокойствие и видимость оперативной стороны. Я использую понятные названия предупреждений. Я делаю так, чтобы владельцев сервисов было легко найти. Я избегаю молчаливых изменений. Я тестирую обновления небольшими порциями перед их широким выпуском. Я просматриваю повторяющиеся инциденты каждую неделю, а не только после крупных сбоев. Эта последняя привычка избавляет от боли больше, чем люди ожидают. Повторяющиеся отключения обычно оставляют подсказки. Подсказки часто невелики: игнорирование предупреждающего сообщения, увеличение лимита, замедление зависимости, ярлык на этапе выпуска. Я обнаружил, что большинству команд не нужно больше драмы. Им нужна лучшая привычка. Больше всего меня волнует то, что меня волнует не столько быстрота, сколько сохранение устойчивости. Система, которая однажды вышла из строя, может восстановиться. Система, которая продолжает давать сбои, подрывает доверие. Клиенты помнят этот пробел. Сотрудники помнят стресс. Группы поддержки помнят эту схватку. Поэтому я прошу свои команды сосредоточиться на следующей неудаче, прежде чем она произойдет. Не со страхом. Со структурой. Именно так я сейчас отношусь к отключениям электроэнергии. Не праздную ремонт и иду дальше. Я закрываю пробел, проверяю путь и оставляю четкую запись. Эта привычка помогла мне избежать одной и той же неудачи более одного раза и сделала каждый ответ чище предыдущего.

Я вижу одну и ту же картину снова и снова: система отключается, страница перестает загружаться, этап оплаты не выполняется, и команда начинает спрашивать, почему никто не предвидел этого. Большинство сбоев не начинаются с большого сбоя. Они начинаются с небольших предупреждающих знаков. Полный диск. Пропущенное обновление. Слабый кабель. Резервная копия, которая никогда не тестировалась. Сертификат, срок действия которого истек, пока все были заняты другой работой. Я узнал, что время простоя часто связано не столько с невезением, сколько с пропущенными проверками. Когда я рассматриваю предотвращение сбоев, я концентрирую свое внимание на простых шагах, которые команда может использовать сразу же: - Проверьте детали, которые выходят из строя чаще всего. Я смотрю на питание, сеть, хранилище, оповещения и сторонние инструменты. Именно здесь обычно начинаются неприятности. - Следите за предупреждающими знаками заранее. Медленная загрузка, всплески ошибок, обрывы соединений и неудачные задания обычно появляются до полного сбоя. Я отношусь к этим знакам как к сигналу, а не как к шуму. - Проверка резервных копий и этапы восстановления. Резервная копия помогает только в том случае, если ее можно восстановить. Я не думаю, что это работает. Я тестирую это. - Сохраняйте одного четкого владельца для каждой критически важной системы. Когда задача принадлежит каждому, она не принадлежит никому. Я распределяю ответственность, чтобы оповещения были видны и были предприняты действия. - Просматривайте изменения перед их публикацией. Небольшое обновление может создать большую проблему. Я предпочитаю простую проверку, прежде чем какие-либо изменения попадут в работающую систему. Реальный пример остался в моей памяти. Однажды я наблюдал, как в напряженный день продаж небольшой интернет-магазин потерял доступ к кассе на несколько часов. Причина не была драматичной. Обновление плагина изменило настройки оплаты, и оповещение попало в почтовый ящик, который никто не просматривал. Заказы замедлились, клиенты ушли, и команде пришлось решать проблему под давлением. Короткая предварительная проверка, лучший маршрут оповещения и проверка резервного платежа полностью изменили бы тот день. Вот почему я советую командам относиться к предотвращению сбоев как к части повседневной работы, а не как к плану спасения. Мне нравятся простые привычки, потому что именно ими люди продолжают пользоваться. Еженедельная проверка системы. Ежемесячный тест восстановления. Четкий путь оповещения. Краткий обзор после какого-либо происшествия. Эти шаги не требуют большого бюджета. Им нужны внимание и последовательность. Моя точка зрения проста: я лучше потрачу немного времени на проверку слабых мест, чем потрачу целый день на исправление поломки. Если система важна для бизнеса, она заслуживает регулярного ухода до того, как возникнет следующий сбой.

Раньше я доверял результату только потому, что раньше работала та же установка. Эта привычка казалась безопасной. Это не всегда было безопасно. Машина может выглядеть хорошо и при этом скрывать износ. Поставщик может отправить один и тот же товар и при этом упустить одну деталь. План может сработать один раз и все равно сломаться, когда условия изменятся. Я видел, как это происходило при проверке запасов в магазине, ремонте дома и платной рекламной кампании. Поверхность выглядела нормальной. Следующий законопроект этого не сделал. Теперь я замедляюсь и проверяю три вещи. 1. Сравниваю, что изменилось. Я смотрю на деталь, цену, состояние или аудиторию, прежде чем повторить тот же ход. 2. Я ищу маленькие знаки. Крохотный треск, небольшое падение отклика, небольшая задержка, слабый сигнал. Маленькие признаки часто появляются перед более серьезной проблемой. 3. Я оставляю один резервный вариант. Запчасть. Второй продавец. Сохраненный черновик. Резервный бюджет. Когда один выбор терпит неудачу, я не начинаю с нуля. Мой друг продолжал использовать тот же дешевый фильтр в кофемашине. Кофе какое-то время все еще был вкусным. Потом машина начала засоряться, счета за ремонт выросли, и кафе потеряло целый день продаж. Проблема не в фильтре сама по себе. Проблема заключалась в привычке предполагать, что следующий раунд будет соответствовать предыдущему. Я больше не люблю делать ставку на привычку. Я предпочитаю новую проверку, спокойный обзор и четкую резервную копию. Это делает маленькую проблему маленькой. Если последний результат выглядел нормально, я все равно задаю один простой вопрос: что изменилось, прежде чем я повторю его?

Я вижу одну и ту же проблему снова и снова: команды ждут сбоя, чтобы выявить слабые места. Это дорогостоящий способ работы. Я наблюдал, как небольшие проблемы перерастали в длительные простои, потому что никто не проверял сигналы заранее. Пропущенное оповещение. Поздний патч. Резервная копия, которая не была протестирована. Одно слабое звено может остановить работу службы, замедлить работу магазина или помешать покупателю оформить заказ. Я предпочитаю простое правило: не гадать. Проверьте, протестируйте и отремонтируйте детали, которые выходят из строя чаще всего. Вот как я к этому подхожу. 1. Я начинаю с наиболее распространенных причин. Я перечисляю проблемы, которые возникают снова и снова: • потеря мощности • перебои в сети • перегруженные серверы • сбои при обновлении • сломанное оборудование • слабые планы резервного копирования Это звучит просто, но многие команды пропускают это. Они сосредотачиваются на новых инструментах и ​​игнорируют все ту же старую линию разлома. 2. Я смотрю на предупреждающие знаки перед отключением электроэнергии, отслеживаю закономерности в журналах, оповещениях и отчетах пользователей. Медленный вход в систему в 9 утра может показаться незначительным. Если это происходит каждый день, это сигнал. Страница оплаты, которая хорошо загружается в тесте, все равно может дать сбой при пиковом трафике. Я видел, как интернет-магазин терял заказы, потому что никто не проверял поведение загрузки перед напряженным днем ​​продаж. Страница рухнула не сразу. Оно замедлилось, затем замерло, затем клиенты ушли. 3. Я проверяю резервный путь, а не только основной путь. Резервная копия, которая никогда не использовалась, — это только надежда. Я проверяю: • может ли система быстро переключиться • достаточно ли емкости резервной копии • актуальны ли файлы • может ли команда достичь ее без задержек Однажды я работал с командой розничной торговли, у которой был сервер резервного копирования, но шаги доступа были скрыты в ветке чата. Во время сбоя два человека искали инструкции, а магазин оставался в автономном режиме. Резервная копия существовала. Процесс этого не сделал. 4. Я постоянно обновляю и обслуживаю старое программное обеспечение, которое может привести к сбоям в работе. Я веду четкий список обновлений и не позволяю обновлениям накапливаться. Я также проверяю состояние оборудования, дисковое пространство и температуру. Это не кричащие задачи. Они поддерживают систему устойчивой. В небольшом офисе, который я посоветовал, был файловый сервер, который постоянно перезагружался. Причина была проста: накопитель был на грани отказа, и никто неделями не проверял предупреждения о хранилище. Спустя одну замену диска перезагрузки прекратились. 5. Я составляю один четкий план ответа. Я не хочу, чтобы команда гадала во время актуальной проблемы. Мой план охватывает: • кто получит первое предупреждение • кто проверяет причину • кто разговаривает с пользователями • как переключиться на службу резервного копирования • как записать исправление Короткие шаги работают лучше всего. В условиях стресса длинные ноты игнорируются. 6. Я проверяю каждый сбой после его завершения. Я всегда задаю три вопроса: • что не удалось • почему предупреждение было пропущено • какая проверка может остановить его в следующий раз Я делаю обзор простым и честным. Никаких игр с обвинениями. Никаких расплывчатых замечаний. Если маршрутизатор вышел из строя, я записываю это. Если оповещение пришло слишком поздно, я исправляю правило оповещения. Если один человек обладал слишком большими знаниями, я распределял шаги по всей команде. Именно так я предотвращаю повторные отключения электроэнергии. Моя точка зрения проста. Отключения не всегда случайны. Многие из них оставляют таблички задолго до остановки службы. Побеждают те команды, которые наблюдают за этими знаками, проверяют запасной путь и четко реагируют. Если бы мне пришлось сократить время простоя, которого можно избежать, с помощью одной привычки, я бы выбрал вот это: проверить слабое место, прежде чем оно станет заголовком.

Моя система пережила один плохой день. Это была ловушка. После отключения приборная панель вернулась. Заказы снова переехали. Клиенты перестали звонить. Я почувствовал облегчение, затем почувствовал еще кое-что, в чем не хотел признаваться: я начал слишком доверять системе. Одно восстановление может скрыть слабые места. Вторая неудача часто их обнажает. Я видел, как это происходило не раз. Небольшой магазин теряет доступ к оплате на час. Команда восстанавливает данные из резервной копии и предполагает, что установка безопасна. Растущая компания сохраняет тот же план серверов, потому что прошлый месяц прошел хорошо. Проблема не первый случай. Проблема заключается в убеждении, что одно выздоровление доказывает долгосрочную безопасность. Я смотрю на выживание системы просто. Если мой бизнес зависит от этого, мне нужны три вещи: - Я хочу знать, что может сломаться - Мне нужен резервный путь, который я действительно могу использовать - Я хочу доказательство того, что восстановление работает, когда давление реально. Это звучит просто. Это также то место, где многие команды ошибаются. Обычно я начинаю с самого болезненного вопроса: что будет, если это снова не удастся? Не то, что должно произойти. Не то, что обещает продавец. Что происходит в напряженный понедельник, когда сотрудники уже отстают, телефон продолжает звонить, а клиент ждет ответа, который так и не приходит? Этот вопрос меняет то, как я планирую. Я перестаю думать только об аптайме. Я начинаю думать о преемственности. Система может быть подключена к сети, но при этом оставаться хрупкой. Страница входа может загрузиться, пока ссылка для оплаты не работает. База данных может присутствовать, но ключевые записи отсутствуют. Облачное приложение может светиться зеленым светом, пока у команды нет доступа к восстановлению файлов. Я видел, как этот разрыв наносил ущерб предприятиям, которые на бумаге выглядели подготовленными. Лучший план обычно включает в себя несколько четких шагов. Я намечаю слабые места. Я спрашиваю, где замедлится бизнес, если эта часть выйдет из строя. Платежи. Записи клиентов. Электронная почта. Инвентарь. Доступ персонала. Если я не могу объяснить воздействие простым языком, значит, я недостаточно глубоко проверил. Я проверяю резервное копирование, а не только политику резервного копирования. Резервная копия, которая никогда не была восстановлена, — это обещание, а не доказательство. Я предпочитаю небольшой тест восстановления, в котором используются реальные файлы, реальные пользователи и фактическое время. Если восстановление занимает слишком много времени или отсутствуют ключевые данные, я хочу узнать об этом заранее. Я веду путь восстановления, по которому люди могут следовать. План, который живет в голове одного менеджера, — это риск. Мне нужны письменные инструкции, четкие роли и контактные данные, которые по-прежнему будут работать, когда стресс высок. Когда возникает проблема, ни у кого нет лишних сил на догадки. Я сокращаю отдельные точки отказа. Одна линия интернета. Одна учетная запись администратора. Одно устройство, контролирующее доступ. Один человек, знающий процесс. Каждый чувствует себя нормально, пока не наступит день, когда он станет узким местом. Я стараюсь распределить риск там, где могу. Я внимательно просматриваю оповещения и журналы. Многие команды замечают проблемы только после того, как их заметили клиенты. Я этого не хочу. Мне нужны знаки до того, как прорыв станет заметен. Медленные ошибки, повторные попытки, неудачная синхронизация, странные шаблоны доступа, задержка резервного копирования. Эти небольшие сигналы часто говорят рано. Розничный клиент, с которым я работал, дал мне наглядный пример. Их веб-сайт отключился из-за короткой проблемы с оплатой. Команда восстановила его в течение дня и почувствовала себя готовой. Месяц спустя в том же стеке возникла проблема с хранилищем. На этот раз резервная копия оказалась старше, чем ожидалось, и процесс восстановления потребовал исправлений вручную. Продажи задерживались, и сотрудникам приходилось снова и снова отвечать на одни и те же вопросы клиентов. Первое выздоровление помогло им выжить. Второе событие показало им, где установка все еще была слабой. Такой урок труден, но полезен. Я также напоминаю себе, что устойчивость – это не разовый проект. Это привычка. Системы меняются. Смена персонала. Изменения в дорожном движении. Продавцы меняются. Установка, которая хорошо работала для небольшой команды, может оказаться неэффективной, когда спрос вырастет. Инструменту, который в прошлом квартале казался стабильным, теперь может потребоваться новая настройка. Я соблюдаю регулярный цикл проверок, потому что молчание не всегда означает безопасность. Мой собственный контрольный список остается простым: - Могу ли я восстановить данные достаточно быстро для обычных деловых нужд? - Сможет ли моя команда получить необходимые инструменты? - Могут ли клиенты по-прежнему выполнять основные действия, если одна часть выйдет из строя? - Знаю ли я, что исправить, прежде чем произойдет следующий инцидент? - Я проверил путь, а не просто прочитал? Мне нравятся простые проверки, потому что к простым проверкам привыкают. Длинные планы часто хорошо смотрятся в папке и остаются там. Короткие планы повторяются. Повторяющиеся действия укрепляют доверие. Это тот момент, к которому я возвращаюсь. Система, которая однажды выжила, не закончена. Это лишь показало мне, где может скрываться следующий риск. Если я буду рассматривать последнее восстановление как доказательство силы, я могу упустить следующее слабое звено. Если я восприму это как предупреждение, я смогу построить что-то более устойчивое. Мне нужны системы, которые делают больше, чем просто возвращаются к нормальному состоянию. Мне нужны системы, которые дадут мне возможность дышать, когда что-то снова пойдет не так. Это означает, что нужно тестировать более одного раза, планировать загруженные дни и делать шаги восстановления достаточно простыми, чтобы их могли использовать реальные люди. Я понял это на практике: выживание — это не то же самое, что готовность.

Я сталкивался с одной и той же проблемой снова и снова: на первый взгляд бизнес выглядит устойчивым, однако на заднем плане продолжают открываться небольшие пробелы. Медленный ответ. Слабое продолжение. Страница, которая сбивает посетителей с толку. Процесс, который работает только тогда, когда один человек помнит каждую деталь. Поначалу эти разрывы кажутся небольшими. Раньше я думал то же самое. Затем я наблюдал, как они превращаются в потерянные продажи, недовольных клиентов и еще больший стресс для команды. Вот почему я уделяю пристальное внимание местам, которые большинство людей игнорирует. Эти тихие слабые места часто наносят наибольший ущерб. То, на чем я концентрируюсь, просто. Я ищу точку, где доверие начинает падать. Если клиент отправляет сообщение и ждет слишком долго, я знаю, что разница заключается не только в скорости. Это уверенность. Если целевая страница дает слишком много информации и не дает четкого следующего шага, я знаю, что проблема не только в дизайне. Это принятие решений. Если отслеживание продаж прекращается после одного сообщения, я знаю, что разрыв вызван не просто усилиями. Это последовательность. Я понял, что скрытые пробелы не дают о себе знать. Они проявляются как небольшие потери, которые люди объясняют. Поэтому я проверяю свой бизнес по частям. Я смотрю на первое впечатление. Я спрашиваю себя, что видит посетитель в первые несколько секунд. Я смотрю на путь от интереса к действию. Я спрашиваю себя, кажется ли следующий шаг простым или тяжелым. Я смотрю на общение. Я спрашиваю себя, звучит ли мое послание ясно, человечно и легко ли ему доверять. Я смотрю передачи. Я спрашиваю себя, остается ли качество обслуживания клиентов гладким, когда одна задача передается другому человеку. Такой обзор избавляет меня от догадок. Один реальный пример остался со мной. У местного сервисного бренда, с которым я работал, было много потенциальных клиентов, стабильный трафик и достойные отзывы. Тем не менее, количество заказов оказалось ниже ожиданий. Причиной было не само предложение. Проблема заключалась в пробеле в форме. Он запросил слишком много информации слишком рано, поэтому многие люди остановились на полпути. Мы сократили форму, перенесли ключевые вопросы позже и сделали следующий шаг более понятным. Изменение не было ярким. Это было практично. Запросы на бронирование улучшились, потому что путь стал легче. Я видел ту же самую картину и в электронной почте. Компания отправляет приветственное сообщение, а затем замолкает. Клиент загружает что-то полезное, но не получает никаких сообщений. Лид проявляет интерес, а затем к нему относятся как к номеру. Это пробел. И оно растет. Когда я хочу решить эти проблемы, я использую простой процесс. 1. Я составляю полный план пути, записывая каждый шаг клиента, от первого контакта до конечного действия. Я не пропускаю скучные моменты. Слабые места обычно прячутся там. 2. Я нахожу шаг, который замедляет людей. Я ищу трения. Дополнительные клики. Сбивающие с толку слова. Задержка ответов. Недостающие детали. Каждый из них может оттолкнуть человека. 3. Я убираю по одному барьеру за раз. Не пытаюсь исправить все за один ход. Начну с проблемы, которая чаще всего блокирует действия. Небольшие изменения легче тестировать и легче сохранять. 4. Я делаю следующий шаг очевидным. Людям не придется гадать, что будет дальше. Я сохраняю прямоту сообщения, простоту действий и удобство просмотра страницы. 5. Сверяю результат с реальным поведением. Слежу за тем, что люди делают, а не только за тем, что они говорят. Если они упадут в одной и той же точке, я знаю, что разрыв все еще существует. Этот подход работает, потому что он уважает то, как люди принимают решения. Большинство людей не уходят, потому что им не нравится все предложение. Они уходят, потому что одна часть кажется неясной, медленной или сложной. Я также считаю, что честная формулировка имеет значение. Я не обещаю того, чего не могу доказать. Я не использую большие претензии для прикрытия слабых систем. Я не прячусь за причудливыми выражениями, когда простые слова делают работу лучше. Это помогло мне завоевать больше доверия. Это также избавило меня от обещаний, о которых я потом пожалею. Сильный бизнес не нуждается в идеальных условиях. Ему нужно меньше слабых мест. Это та часть, к которой я постоянно возвращаюсь. Если я обнаружу пробел раньше, я смогу исправить его до того, как он перерастет в более серьезную проблему. Если я игнорирую это, я обычно расплачиваюсь за это позже временем, энергией и упущенными возможностями. Поэтому я продолжаю проверять. Продолжаю подстригать. Я продолжаю делать путь более легким для прохождения. Эта привычка помогла мне оставаться устойчивым, когда другие начинают падать. И если бы мне пришлось сложить это в одну строку, я бы сказал так: не ждите, что маленькие разрывы станут большими потерями. Найдите их, столкнитесь с ними лицом к лицу и исправьте их, пока с ними еще можно справиться. Хотите узнать больше? Не стесняйтесь обращаться к Лю Линлину: 69099474@qq.com/WhatsApp +8615058970517.

Джон Оллспау, 2015 г. Проектирование надежности и человеческая сторона сбоев Джин Ким, 2018 г. Руководство DevOps Как создать гибкость мирового класса, надежность и безопасность в технологических организациях Николь Форсгрен, 2018 г. Ускорение науки бережливого программного обеспечения и DevOps Команда Google SRE, 2019 г. Проектирование надежности сайтов Как Google управляет производственными системами Atlassian 2021 Рекомендации по управлению инцидентами для более быстрого восстановления Amazon Web Services Основа надежности AWS Well Architected Framework 2022 года