Лекция «Изменения и окно обслуживания»

Около 65 минут на 18 тем. Прогресс сохраняется, поэтому лекцию можно проходить частями и возвращаться к ней позже.

Начало — да: первые 1 тема открыты сразу, без регистрации. После бесплатной регистрации откроются темы до 2-й — вместе с частью из 51 теста и монетами за верные ответы. Полная лекция — 99 ₽ навсегда, либо подписка на все лекции платформы от 499 ₽ в месяц.

Восемнадцать тем о том, как вносить изменения в живую инфраструктуру и не превращать их в отложенные инциденты. Начало — цифры: около 70% сбоев у Google вызваны изменениями в живой системе (число принадлежит Google и описывает Google, вариант «80% по данным Gartner» проверяемой публикации не имеет), четверо из пяти респондентов Uptime Institute считают свой последний серьёзный сбой предотвратимым лучшими процессами, 54% оценили его стоимость выше $100 000, а 16% — выше $1 млн. Дальше нормативный каркас, разобранный по адресатам: пункт 13.4 приказа ФСТЭК России № 239 с четырьмя подпунктами, где санкционирование стоит отдельным действием от документирования, а процессы обязаны охватывать техническое обслуживание, в том числе дистанционное; пункт 17 постановления Правительства № 676, по которому развитие государственной системы идёт по правилам её создания за вычетом концепции, и исключение пунктов 17(3)–17(4) с вводом компонента на следующий рабочий день после утверждения протокола; Положение Банка России № 850-П от 13.01.2025, заменившее утратившее силу 787-П, с прямой нормой о невключении плановых технологических операций в расчёт простоя и порогами Приложения 1 — 2, 4 и 6 часов по размеру организации и 2 часа по счетам для всех; меры группы ЖЦ из ГОСТ Р 57580.1-2017 и пункт 8.5.1 ГОСТ Р ИСО/МЭК 20000-1-2021, требующий заранее определить категорию аварийного изменения и планировать откат до внедрения. Практическая часть строится вокруг классов обратимости, списка необратимых действий и двух разборов: GitLab 31 января 2017 года, где из пяти механизмов резерва сработал один внеплановый, а восстановление заняло около 18 часов, и CrowdStrike 19 июля 2024 года, где 20 ожидаемых полей против 21 присланного вывели из строя около 8,5 млн устройств, притом что тот же механизм пять месяцев работал без единого сбоя. Окно обслуживания разобрано честно: оно ограничивает радиус поломки и время её незамеченности, но вероятность сбоя не снижает; заморозка изменений показана как развилка с ценой на обеих сторонах. Завершают лекцию форма запроса санкции из пяти строк с примером письма, три правила о границах подтверждения, список предупреждаемых, в котором программные сервисы стоят наравне с людьми, и девять шагов, к которым всё сводится. Юридических консультаций лекция не даёт и не обещает, что соблюдение процедуры снимает ответственность.

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

Затем, что это готовые формулировки процесса, который иначе приходится изобретать самому. Лекция всё время держит границу: пункт 13.4 приказа ФСТЭК № 239 обязателен для значимых объектов критической информационной инфраструктуры, Положение № 850-П — для кредитных организаций и филиалов иностранных банков, постановление № 676 — для государственных органов. Для остальных это добровольная рамка, и переносить чужую обязанность на себя целиком так же вредно, как игнорировать свою. Отдельная тема разбирает, где именно проходит эта граница.

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