Надёжность и безопасность
Все рассчитывают на защиту. Кто знает, как она работает?
Если от системы зависит выручка или важные решения, до следующего инцидента нужно разобраться, как она может отказать. Затем проверить уровни защиты и определить, кто за них отвечает.
Сигнал
Нагрузка и атаки усиливаются, неясностей в работе становится больше. Понять, справляется ли текущая защита, всё труднее.
Система ломается на стыке провайдеров и команд, пока каждый уверен, что соседний уровень защиты уже всё прикрыл.
Почему работа застревает
Проблемы надёжности часто скрываются за привычным объяснением: этим занимается CDN, облако или платформенная команда. Иногда защиту приписывают старому архитектурному решению, хотя на деле нужный участок никто не контролирует.
Повод разобраться появляется, когда никто не может проследить сценарий отказа целиком и сказать, в какой момент автоматика должна передать решение человеку.
С чего начинаю проверку
Сначала разбираю реальный сценарий отказа и проверяю, какие уровни защиты должны сработать.
С чего начинаю проверку
- Ситуация
У работающей системы есть слабый участок: под нагрузкой или атакой он может отказать, а ответственность за него неясна.
- Ограничение
Защита закрывает не все участки, местами дублируется, а ответственность за неё размыта.
- Решение
Описать сценарий отказа и роль каждого уровня защиты. Определить, кто следит за системой и кому передаёт инцидент.
- Что изменилось
Ещё до следующего инцидента становится понятно, как система выдерживает сбои и кто за это отвечает.
Что можно изменить за один шаг
Для первого шага берём один сценарий отказа и проверяем защиту от него.
Защита работает, когда согласованы её уровни, обязанности провайдера и ответственность за действия внутри системы.
Здесь описана роль каждого уровня защиты. Неподтверждённых заявлений о масштабе атаки нет.
- Контекст
- Реальная атака и пределы защиты работающей системы.
- Период
- Запись из практики автора
- Роль
- Operational CTO
- Источник
- Кейс о многослойной защите
- Откуда данные
- Материалы автора с оговорками к выводам. Часть данных нельзя раскрывать.
- Надёжность данных
- Источник подтверждает этот случай. Более широкие выводы нужно отдельно проверить и согласовать.
- Ограничения публикации
- Клиент не назван. Неподтверждённые показатели не приводятся.
Связанные кейсы
Что показывает практика
Надёжность и безопасность
Внешняя защита остановила одну часть атаки, но внутри приложения всё ещё требовалось активно ей противодействовать.
- Решение
- Разделить обязанности провайдера и действия команды внутри системы.
- Результат
- Защита стала многослойной и управляемой.
- Роль
- Operational CTO
Надёжность и безопасность
Цена инфраструктуры, возможности управления и риск сбоев оказались связаны иначе, чем ожидала команда.
- Решение
- Перестроить платформу, явно определив цену решений и ответственных за их последствия.
- Результат
- Пределы надёжности системы стали понятнее.
- Роль
- Operational CTO
Стабильный выпуск продукта
Система стала уязвимее, когда за одну ночь ушёл руководитель со знаниями о её работе.
- Решение
- Временно взять ответственность за работу системы, пока очередной сбой не стал проблемой без объяснения и ответственного.
- Результат
- За работу системы снова стал отвечать конкретный человек, не дожидаясь полной передачи дел.
- Роль
- Operational CTO
Field Notes
Заметки, которые помогут разобраться
За внедрение ИИ должен кто-то отвечать
Инструменты уже пробуют. А кто решает, как менять работу нескольких команд? Разбираю, зачем внедрению ИИ нужен ответственный с полномочиями.
Открыть заметкуКод свежий, а менять его уже тяжело
У продукта длинный план, а команда пишет код на ближайшую задачу. Как это расхождение видно в репозитории и что с ним делать.
Открыть заметкуFit / No-fit
Когда формат подходит
Подходит
- Система уже работает, а сбой имеет реальные последствия.
- Команда готова разобрать весь путь от внешнего запроса до приложения и действий человека.
- Нужна работающая защита на нескольких уровнях с понятной ответственностью.
Не подходит
- Нужен только чек-лист соответствия требованиям, без разбора работающей системы.
- Руководству нужно обещание неуязвимости.
- Компания не готова разделить обязанности провайдера и собственную ответственность за защиту.
Activation Sprint
Начать с Activation Sprint
В первом платном проекте разбираем один реальный сценарий и защиту от него. Определяем, кто в команде отвечает за следующие решения.
Neutral start
Расскажите о сбое или слабом месте
Если системе трудно доверять, но сценарий отказа ещё неясен, опишите, что вас беспокоит.