Надежность и устойчивость для руководителя

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

• Структура пирамиды Захмана: информационная архитектура, данные, приложения и инфраструктура
• Принцип наследования критичности
• Обратная проверка критичности (когда критичный компонент нельзя связать с критичным информационным потоком)
• Разграничение ответственности по слоям
• Принципы резервирования в соответствии с критичностью

Теория информационных потоков и информационной архитектуры с закреплением на практике.

• Отличие объекта информации от информационного потока
• Классы критичности информационных потоков и почему core и mission critical – не одно и то же
• Структура оценки информационного потока с точки зрения надежности
• Split-brain на уровне бизнеса и его последствия
• Внешние события и их влияние на информационные потоки
• Скрытая связанность информационных потоков через технические решения
• Зависимость связанности информационных потоков от отрасли

• Понятия SLA и SLO
• Понятия RTO и RPO и их применение внутри информационного потока
• Инфраструктурные ограничения RPO
• Фиксация среза потерь данных при аварии
• Правила работы с резервными копиями
• Особенности требований 152-ФЗ, 787-П, ГОСТ Р 57580

• Выявление приложений, оперирующих критичными объектами данных
• Понятие и признаки единой точки отказа
• Схемы active-passive и active-active
• Скрытые зависимости на уровне приложений (AD/LDAP, DNS, лицензии, мониторинг, репозитории)
• Понятие автономности сервисов при отказе соседей
• Почему при переезде разваливаются кластеры и отваливается CI/CD?

• В чем разница между DR и BC и почему нужны оба?
• Понятия холодного, горячего и теплого резерва
• Определение количества резервных дата центров
• Канал связи как потенциальная единая точка отказа
• Принципы подготовки к экстренному переезду инфраструктуры
• Инфраструктура как код и доверенные инструменты развертывания инфраструктуры
• CI/CD как элемент критичной инфраструктуры

• Выведение стоимости простоя из информационной архитектуры
• - Прямые потери (Транзакции, штрафы по SLA, сверхурочные работы на восстановление)
• - Для внутренних систем потери считаются через последствия. Например: зарплата не выплачена вовремя, отчетность регулятору просрочена, Compliance-проверки остановлены.
• - Регуляторные и репутационные последствия (предписания ЦБ, инциденты в отчетности по 787-П)
• - Ожидаемый годовой убыток (ALE) = стоимость часа × длительность × вероятность в год.
• Стоимость резервирования
• - Кривая стоимости (каждая следующая «девятка» и каждое сокращение RTO обходятся непропорционально дороже)
• - Точка разумности (резерв не должен стоить больше убытка, который он предотвращает)
• TCO вариантов резерва
• - CAPEX (оборудование и лицензии)
• - OPEX (площадка, электричество, каналы, поддержка, дежурства)
• - Скрытые затраты (двойные лицензии, регулярные DR-тесты, люди, простаивающее резервное железо)
• - Российская специфика (сроки поставки (ожидание тоже стоит денег), параллельный импорт без гарантии и потому необходимость ЗИП, рост цен на память, курсовой риск, российские облака как альтернатива капитальным затратам)
• - Сравнение вариантов (холодный резерв, теплый, горячий, облако)
• Защитить или урезать
• - Язык для финансов («вложение X снижает ожидаемый убыток на Y в год»)
• - Три варианта на выбор (минимальный, рекомендуемый и максимальный, с последствиями каждого)
• - Урезать нужно обоснованно, а не «минус 20% всем» (понизить класс критичности, предусмотреть деградацию, уменьшить тестовые среды, закупать поэтапно)

• Трассировка от железа к информационному потоку
• Красные флаги, или – на что обращать внимание в сайзинге, архитектуре и спецификации

• Как работать при дефиците оборудования и пиковых нагрузках
• Capacity planning
• Graceful degradation и load shedding (что отключаем первым)
• Аварийные резервы

Как мы узнаем, что план сработает?

• Tabletop-учения (самый дешёвый способ проверки, зона руководителя)
• Runbook (роль руководителя инцидента, эскалация и коммуникация с бизнесом)
• Bus factor (legacy-системы, которые знают 2–3 человека)
• Chaos engineering (как ориентир на будущее)

• Ролевая игра. Инфраструктура приносит заявку, участник проверяет ее по карте красных флагов, пересчитывает TCO и готовит позицию для финансов (защитить или урезать)
• Возврат к пятнице, 18:00: «Что вы теперь сделаете иначе?»

• Объемы взяты «как у соседей» или «на вырост», а не из фактической утилизации.
• Запас поверх запаса, каждый уровень (команда, инфраструктура, вендор) добавляет 20–30%, и в итоге получается почти вдвое больше нужного.
• Утилизация CPU в проде ниже 20%, а просят еще.
• Рост более чем в 2 раза без бизнес-плана, который его объясняет
• Тестовая среда по размеру равна проду
• Не учтены дедупликация, сжатие
• Срок хранения бэкапов больше, чем требуют регулятор и бизнес

• На схеме нет каналов связи и внешних зависимостей
• Одна СХД на оба «плеча»
• Второе «плечо» в том же здании или на той же энергосети
• Не обозначен кворум
• Не указаны RTO и RPO, под которые строилось решение

• Топовые CPU там, где нагрузка этого не требует. При лицензировании СУБД по ядрам лишние ядра удорожают лицензии.
• Поддержка 24/7 для некритичных систем.
• Дублирование позиций и отсутствие ЗИП.
• Не проверены сроки поставки, совместимость с реестром отечественного ПО и наличие альтернатив.

• Участники разбирают учебный пакет (сайзинг, схема, спецификация) с 8–10 заложенными ошибками и ищут их.

• личная карта красных флагов