200 Заключение

Как сделать надежную ИТ систему:

1. Проектирование
   1. Заложить возможность детектирования сбоев
   2. Заложить мониторинг внутренних исчерпаемых ресурсов
      1. Пулы соединений
      2. Очереди
      3. Воркеры
   3. Заложить мониторинг зависимостей
   4. Найти моменты, где мы можем разменять консистентность на большую доступность
      1. Кеши
   5. Определиться нужно ли скалироваться горизонтально (шардироваться) и выбрать, как это будет работать
      1. Средствами какой-либо БД
      2. Самим приложением
   6. Заложить возможность отключать тяжелый функционал, который предоставляет удобство пользователю
   7. Заложить возможность быстрой починки выключением сбойный участков из балансировки
   8. Поделить на разные сервисы, то что можно быстро и безопасно рестартовать и то, что нельзя
   9. Для нагруженных приложений
      1. Заложить возможность включения дебаг логов для запроса
   10. Если заботит выполнение каждого запроса
       1. Сделать все такие операции идемпотентными (возможно с ключом дедупликации)
       2. Исплользовать "Сагу" с ACID хранилищем для статуса запроса и идемпотентными стадиями
   11. При проектированиии системы учитывать простоту обучения, логичность и вероятные ошибки, из-за того, что инженер что-то не знал или забыл в моменте
2. Надежный код
   1. Выставить таймауты на всех внешних вызовах
   2. Рассказать о своих таймаутах в документации
   3. Понять, где необходимо использовать повторы и реализовать
      1. Не забыть про бюджеты ретраев
   4. Уметь автоматически выключать запросы на внешние причины, чтобы не убивать их нагрузкой, если они не отвечают или отвечают с ошибкой
   5. Убедиться, что правильно пишем ERROR логи (свидетельствуют именно о возникновении нештатной ситуации)
      1. Добиваемся полного отсутствия ошибок в логгах при штатной работе
   6. Уделиться, что возвращаем правильные ошибки
      1. не корректный запрос
      2. наша внутренняя ошибка
   7. Ограничиваем максимальное входящее количество запросов (rate-limit)
3. Устойчивый клиент
   1. Добавляем в клиент возможность отобразить сообщение, когда бек не работает (через примитивный CDN)
   2. Тестируем клиент на то, что он не разваливается при недоступности части API
   3. Закладываем возможности удаленного администрирования клиента (сброс кешей и т.п.)
4. Тестирование
   1. Тестируем адекватность работы, когда сломались зависимости и восстановление
   2. Тестируем работу под нагрузкой, кратно превышающей максимальную рассчетную, и восстановление при возвращении к максимальной рассчетной
   3. Тестируем в продакшен
5. CI/CD
   1. Делаем более безопасные релизы
      1. Canary и другие методики
      2. Конфиги и выкладывание новых данных/справочников — тоже релиз
6. Мониторинг
   1. Мониторим работу самого функционала
   2. Используем тестирование в продакшен — проберы
   3. Система алертирования звонит на телефон
   4. Дежурные подтверждают прием алерта, в противном случае эскалация на второго дежурного, всю команду, руководство
7. Детектирование сбоев
   1. Реализованы достаточно надежные способы детектирования сбоев, которые не дают false positive/false negative
   2. Хранится история всех сбоев
8. Команда эксплуатации
   1. Есть специальное обучение для инженеров проекта
   2. Есть документация по продакшену
   3. Есть регулярная встреча с обзором всех текущих проблем продакшена
9. Процессы
   1. Проект можно очень быстро зарелизить
   2. Проект разрабатывается так, что его всегда можно откатить на несколько версий назад (минимум на 3 месяца)
   3. Откат проекта быстрый
   4. Есть план восстановления "с нуля" — DRP
   5. Регулярно проводятся учения
      1. Виртуальные
      2. Реальные
   6. Дежурные реагируют на каждый единичный алерт
   7. После сбоев делается детальный разбор
   8. Задачи после разбора сбоев имеют высокий приоритет и сразу берутся в работу
   9. Разработаны классификации причин и триггеров сбоев, сбои размечаются для сбора статистики
   10. Избегаем хождения на прод и ручных изменений в нем