Андрей Зарубин

Паттерн запуска задач по расписанию и области его применения.

Варианты реализации паттерна средствами JDK.

Quartz и его аналоги.

Запуск задач по расписанию в Spring Framework.

Внешние планировщики задач.

Ограничения в реализации.

Особенности тестирования.

В российских IT-компаниях термин SRE стал модным синонимом эксплуатации.

При этом в оригинале SRE - это конкретные принципы эксплуатации, сформулированные в Google, и они являются естественным продолжением остальных особенностей культуры внутри Google и не факт, что подходят любой другой компании, тем более в России.

Что же было до появления SRE? Те, кто работал в крупных компаниях, могли сталкиваться с ITIL - библиотекой лучших практик.

ITIL имеет намного большую сферу приложения, чем SRE, но следующие части ITIL пересекаются с SRE:

* Управление доступностью

* Управление производительностью

* Контроль за изменениями

* Управление инцидентами

* Мониторинг и реакция на события

* Управление проблемами

* Управление релизами

* Управление конфигурацией

* Управление непрерывностью

* Процессы поддержки

* Менеджмент SLA

* Менеджмент заявок

* Управление валидацией и тестированием

* Управление развёртыванием

* Управление инфраструктурой и платформами

* Управление разработкой

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

На фоне ITIL SRE превращается в "мы не объясним как вам наладить эксплуатацию, но вы должны быть инженером и писать код". Фундаментальные вещи в SRE: риски, SLO/SLI, мониторинг - это база в ITIL, которую в ITIL уже снабдили подробной инструкцией по внедрению.

Место SRE - в треугольнике с ITIL и DevOps. С одной стороны SRE не предлагает принципиально новых процессов эксплуатации, а с другой предлагает конкретную реализацию принципов CALMS из философии DevOps.