Восстановить работу, не уничтожив улики
Четыре утра, сервис лежит. У вас в руках две команды: одна возвращает работу за тридцать секунд, вторая сохраняет состояние системы, в котором записана причина отказа. Кажется, что выбрать можно только одну. Это и есть главное заблуждение первых минут, и разбирается оно не уговорами, а арифметикой: несобранное состояние собрать потом нельзя вообще, а восстановление, отложенное на пять минут, стоит ровно пяти минут.
Разговор идёт сразу для двух ролей. Системный администратор приходит сюда с физическими и виртуальными серверами, журналами systemd, забитым диском и службой, которая не поднимается после перезапуска. DevOps-инженер — с контейнерами, оркестратором, конвейером выкатов и откатом релиза. Предметы разные, порядок действий один, поэтому примеры в темах чередуются.
- назвать по порядку, что именно исчезнет при перезагрузке этой машины, и снять это до неё;
- проверить командой, а не памятью, где лежит журнал и переживёт ли он перезапуск;
- различить команды, которые сохраняют контейнер, и команды, которые уничтожают его вместе с журналом;
- освободить забитый диск, не потеряв открытый файл;
- вести журнал смены так, чтобы через час было понятно, что вы уже сделали;
- назвать срок, в который надо сообщить о случившемся, и отсчитать его от правильного момента.
Разбора после инцидента: документа, хронологии, поиска первопричины и раздачи задач — это отдельные лекции каталога. Стратегии резервного копирования, организации дежурства и политики хранения журналов — тоже. Здесь только то, что делается руками, пока сбой идёт, и пока ещё не поздно что-то сохранить.
Уровень предполагает, что ps, journalctl и контейнер объяснять не нужно. Нужно объяснить, что именно из них исчезает — и когда.
Восстановить или сохранить — дилемма, которой нет
Аргумент против сбора данных всегда один: люди ждут, каждая минута простоя стоит денег, некогда заниматься криминалистикой. Аргумент честный, но он сравнивает несравнимое. Восстановление, отложенное на пять минут, стоит пяти минут простоя. Состояние, не снятое до перезагрузки, не стоит ничего — его просто больше нет, и завтрашний разбор будет вестись по догадкам.
Эту асимметрию можно не выводить самостоятельно: она уже записана в национальном стандарте. ГОСТ Р 59712-2022 «Защита информации. Управление компьютерными инцидентами. Руководство по реагированию на компьютерные инциденты» утверждён приказом Росстандарта от 29.11.2022 № 1378-ст; основополагающий стандарт серии — ГОСТ Р 59710-2022.
Две дорожки вместо очереди
Раздел 6 стандарта перечисляет этапы стадии реагирования — это дорожка восстановления:
А раздел 7 выносит в отдельные этапы фиксацию материалов, связанных с возникновением инцидента, и установление причин и условий его возникновения. Это не продолжение списка выше, а вторая дорожка.
«Данные этапы могут проводиться параллельно с остальными этапами реагирования и даже после этапа "закрытие компьютерного инцидента". Выполнение данных этапов не влияет на закрытие компьютерного инцидента.»
Читается это в обе стороны, и вторая сторона важна не меньше первой. Восстановление не ждёт окончания фиксации — стандарт прямо запрещает делать фиксацию условием закрытия. Но и фиксация не отменяется тем, что работу уже вернули: она законно продолжается после закрытия инцидента. Отменяет её только одно — перезагрузка, выполненная раньше, чем снято летучее.
Сисадмин: служба не поднимается, диск полон. Пока копируется содержимое открытого журнала, служба уже не работает — время идёт в обе стороны одинаково, но копия займёт минуты, а перезапуск без копии закроет вопрос навсегда.
DevOps: под падает по кругу. Снять журнал предыдущего запуска и описание пода — это два вызова; удалить деплой и раскатать заново — один. После второго варианта причины падения не существует нигде.
Дальше нужен аккаунт
Прогресс и монеты сохранятся.