Изменения и окно обслуживания
Инфраструктура ломается не сама по себе. По данным Google о собственной инфраструктуре, около 70% сбоев вызваны изменениями в живой системе. То есть главный источник аварий — не железо, не злоумышленник и не погода, а человек, который что-то поправил.
Эта лекция — про порядок, который один администратор может выполнить в понедельник, без отдела информационной безопасности и без процесса согласований на бумаге. Как отнести изменение к классу, как записать откат до действия, у кого и какими словами спросить разрешение, кого предупредить и что делать, когда отката не существует.
«Обновил заодно» — не экономия времени, а отложенный инцидент. Изменение, сделанное попутно и не записанное, всплывает не в момент правки, а через неделю, когда никто уже не помнит, что трогали.
Что внутри
- Норма как каркас: приказ ФСТЭК России № 239, постановление Правительства № 676, Положение Банка России № 850-П, два ГОСТа — кому что адресовано и что именно они требуют
- Классы обратимости: как определить класс по худшему исходу, а не по намерению
- Откат: где он есть, где его нет и чем он заменяется, когда его нет
- Окно обслуживания: что оно даёт, чего не даёт и почему заморозка изменений — развилка, а не рекомендация
- Санкция владельца и предупреждение потребителей — в форме, пригодной к применению
- Девять шагов, к которым всё сводится
Настроек конкретных операционных систем, сетевого оборудования и средств защиты информации: это требует стенда, а не текста. Разбора инцидента и пост-мортема, дежурств и графиков, трудового оформления ночных работ, методики инвентаризации, расчёта показателей резервного копирования — у каждой из этих тем своя лекция. Юридических консультаций лекция не даёт и не обещает, что соблюдение процедуры снимает ответственность.
Семь сбоев из десяти приходят из ваших рук
В первой главе книги Site Reliability Engineering Google формулирует это прямо: «SRE has found that roughly 70% of outages are due to changes in a live system». Примерно семьдесят процентов сбоев — следствие изменений в работающей системе.
Цифру 80% с такой атрибуцией повторяют часто, но проверяемой публикации с ней найти не удалось. Работает только одно число — 70%, и только со ссылкой на Google. Это измерение Google по своей инфраструктуре, а не константа индустрии: у вас доля может быть другой.
Что говорят сами операторы
Uptime Institute в ежегодном разборе сбоев за 2024 год приводит самооценку респондентов: четверо из пяти сказали, что их последний серьёзный сбой можно было предотвратить лучшим управлением, процессами и конфигурацией. Это не независимый разбор причин, а мнение операторов постфактум — но мнение показательное: они винят не технику, а порядок работы.
Вторичные публикации по этому же отчёту называют 20% вместо 16%. В первоисточнике — 16%. Если встретите 20%, знайте, что это пересказ пересказа.
Там же полезное разделение: самая частая причина серьёзных и тяжёлых сбоев центров обработки данных — проблемы с электропитанием, а крупнейшая единичная причина сбоев ИТ-сервисов — сетевые проблемы. Питание роняет площадку, сеть роняет сервис. Вторая категория — ровно та, куда попадает правка правил фаервола и запись DNS, сделанная между делом.
Дальше нужен аккаунт
Прогресс и монеты сохранятся.