100 Код устойчивый к сбоям

Слайды на отдельной странице

Чтобы код был устойчив к сбою:

• таймауты
• репиты
• выключатели
• опциональное должно быть опциональным

Чтобы сбои проходили легче:

• код должен быстро рестартовать
  • если код рестартует медленно то то, что требует долгого рестарта выносим в отдельный минимальный сервис
• приложение должно быстро релизиться и откатываться
• приложение всегда обратно совместимо с предыдущей версией, никаких неоткатываемых релизов
• модификация схемы данных всегда обратно совместимы
• плавно обновляем данные (сохранение данных это как вызов API отправленный в будущее)
  • либо медленным процессом
  • либо приложение, встретив старый формат, конвертирует его в новый формат
• обновления через feature-флаги
• позволяет менять уровень логгирования через API
  • в частности позволяет сделать API вызов с требованием логгировать детальней все, что относиться с этим и только этим запросом

Обновлению данных помогает если мы все поля считаем опциональными и только добавляем новые поля, а старые не удаляем, но постепенно перестаем использовать.

Чтобы код нормально диагностировался:

• входящие RED метрики
• исходящие RED метрики
• метрики использования разделяемых, исчерпаемых, забиваемых ресурсов
  • кеши
  • буферы
  • очеререди
  • пулы
• метрики состояния
• логи являются внешним API (!) приложения
  • обратная совместимость
  • проектировать
  • не писать лишнего
  • логи библиотек — мусор для дебага при разработке, но не в проде
    • не знаете поведения ваших библиотек — не знаете, что же вы написали

Метрики использования ресурсов должны быть кумулятивными метрикими времени удержания ресурса (как и все быстро меняющиеся метрики).

Опциональный функционал

Опциональный функционал должен быть истинно опциональным, то есть при неработоспособности не ломать основное.

TODO(d.maslennikov): Где рассказать про канарейку?