Есть мнение, что знания по SRE нужны только тем, кто работает в гигантах типа Google или Netflix. Но проблемы с надёжностью часто возникают из-за человеческого фактора. Ценность подхода SRE как заключается в том, чтобы его минимизировать. То есть постепенно создать культуру ответственности и сотрудничества, что важно как для большой, так и для маленькой компании.

Собрали чек-лист проблем, которые говорят о том, что стоит присмотреться к SRE-практикам.

1. Проблемы с надежностью 

???? Сбои дорого обходятся для бизнеса, как финансово, так и репутационно. Например, если IT-инфраструктура Amazon остановится на минуту, потери сервиса составят порядка 66 240 долларов. Посчитайте, сколько стоит 1 час простоя вашего сервиса?

???? Большие затраты на восстановление. Эти затраты тоже можно посчитать, но очевидно, что запущенные проблемы решать сложнее. Пусть ваши аналитики посчитают, что дороже: инвестировать в SRE или оставить всё как есть.

???? Кибератаки. По данным исследования Positive technologies за первый квартал 2023 года количество инцидентов, связанных с кибератаками, увеличилось на 7% по сравнению с предыдущим кварталом. Чаще всего атакам подвергались госучреждения, медицинские организации и финтех. Скорее всего, компаниям придется всё больше инвестировать в кибербезопасность и надёжность.

???? Непредсказуемое поведение системы. Например, в системе появились задержки отклика, а через 10-15 минут симптомы прошли. Но причина осталась и её нужно выяснить.

???? Сбоев нет, но страшно, что он когда-нибудь произойдет, а вы отвыкли и не готовы к нему. Нужно тренироваться, чтобы в случае реальной угрозы не паниковать и действовать эффективно.

2. Отсутствие операционной экспертизы 

???? Команда разработчиков не обладает достаточной экспертизой в области операций и инфраструктуры. Знаем, что где-то что-то упало, но не знаем, как чинить. Знакомая ситуация?

???? Архитекторы системы уволились, а тех, кто знает, как всё устроено, мало. Оцените, сможете ли вы всё поднять по документации силами небольшой команды?

???? Есть проблемы с выгоранием и низкой культурой у разработчиков и инженеров. Например, откладывают починку на потом, не повышают квалификацию, а в кризисной ситуации ищут виноватых, вместо того, чтобы разбираться с проблемой.

3. Значительный рост и масштабирование системы 

???? Система быстро растет по объёму данных, пользователей или количеству серверов. С каждым новым масштабированием риск сбоя увеличивается по экспоненте. При этом бизнес может считать, что штатные инженеры смогут всё это контролировать.

???? Есть проблемы с масштабируемостью и производительностью. Если уже сейчас наблюдаются такие проблемы, то в дальнейшем всё может усугубиться: конфигурации станут сложнее, стоимость восстановления возрастёт. Надо стелить соломку.

4. Недостаточный мониторинг и отладка 

???? Отсутствуют эффективные инструменты мониторинга и отладки. Без них сложно предлагать решения по оптимизации, трудно обнаруживать и устранять проблемы. Никто не видит, как всё работает.

???? О проблемах становится известно слишком поздно. Если вам пришел алерт, то это уже хорошо. Но лучше, если с помощью инструментов мониторинга, вы найдете проблему до такого, как всё упадет.

5. Неэффективные операционные процессы 

???? Много рутины и ошибок из-за человеческого фактора. Существует консенсус, что инженеры по надёжности должны тратить на операционные задачи не более 50% своего времени. То есть как минимум половину времени следует заниматься повышением производительности и оптимизацией ручного труда. Если тонете в текучке — отмечайте этот пункт.

6. Пользователи недовольны 

???? Клиенты или пользователи жалуются на проблемы с сервисом. Чтобы достигать бизнес-цели, необходимо анализировать эти жалобы и решать проблемы. Если их количество увеличивается, это тревожный знак.

???? Клиенты и пользователи не жалуются, но перестают его использовать. Если пользователи уходят ничего не сказав, это ещё более тревожный знак, придется потратить ещё больше усилий на то, чтобы установить причину.

Заключение

Помните, что каждая ситуация уникальна, и решение о внедрении SRE следует принимать с учетом конкретных потребностей и целей организации. Этот чек лист поможет оценить, какие существуют проблемы, но насколько они критичны — решать вам.

Чтобы ближе познакомиться c методологией SRE и научиться внедрять эти практики, приходите на курсы Слёрма. Вот курсы, которые стоит пройти, чтобы получить теоретический и практический опыт по SRE:

???? SRE: data-driven подход к управлению надежностью систем. Старт — 22 августа.
???? SRE: Observability. Старт — 24 июля.

Ознакомиться с программой и записаться на курс можно на нашем сайте.