Современная разработка уже подразумевает интеграцию
DevOps в цикл разработки программного обеспечения. Хороший разработчик уже не только разрабатывает программу, а еще и думает как она будет доставляться в продакшен; работать там; что мы будем мониторить, чтобы понимать, что наш сервис в порядке.Это здорово. Но может быть еще лучше. Как выглядит цикл разработки у большинства команд? Он может выглядеть так:
1. Обдумали новую фичу
2. Запрограммировали ее
3. Обложили метриками
4. Зарелизили
5. Мониторим
6. Потом вернуться к пункту 1
И вот, когда Хороший разработчик возвращается к пункту 1, то у него физически и когнитивно становиться меньше времени на пункт 5, то есть на поддержку программного обеспечения в продакшене. Я тоже сталкиваюсь с этим.
Для решения этой, и не только этой проблемы, сейчас выделяют роль
Site Reliability Engineer (SRE). Основная ответственность человека, который исполняет эту роль, в том, чтобы ваша система оперировала, была resilient и по-умному redundant. Этот инженер, как правило, напрямую не связан с разработкой сервисов, но он(а) знает как ими оперировать, как их мониторить, что делать когда что-то идет нет так. Так же этот человек участвует в on-call и исправляет проблемы.
Важной частью
SRE практик является автоматизация (operations as code). Конечно что-то пойдет не так, это точно произойдет. Но важно, чтобы из этого были сделаны выводы и больше это бы не повторилось. SRE, вместе с командой анализирует инциденты, делает выводы и вносит изменения в инфраструктуру, чтобы проблемы не повторились.⬛️ Еще раз — хорошо когда есть кто-то, кто постоянно следит за тем, что система хорошо работает в продакшене. Лучше, когда это еще и постоянно оптимизируется. Для этого кто-то должен выполнять
SRE роль. В небольших и средних компаниях, это общая роль и за нее ответственна вся команда, но лучше, когда это отдельная позиция или даже команда.У вас в компании есть
SRE? Пишите в комментариях#хардскиллы
