Я начал работать инженером по надежности сайта довольно давно. За это время, прошел разные пути и окунулся во все процессы компаний, с которыми им приходится сталкиваться в поиске человека на подобную должность:

• Недостатком знаний о том, что же означает роль SRE в работе
• Адаптацией
• Ростом
• Повторной адаптацией
• И вновь повторением сначала.

Примите факт, что Вы являетесь SRE не потому, что заботитесь о надежности, все заботятся о надежности, а потому, что система слишком сложна для управления человеком, который также занимается другими делами.

Нет никаких различий с любым другим «первым нанятым» в компании. Даже первого менеджера проекта нанимают, когда человек, который выполнял эту работу, уже не может ее делать, потому что компании нужен кто-то, на 100% ориентированный на продукт.

Инженер по надежности сайта должен повысить надежность обслуживания. Видимость, наблюдаемость, ведение протоколирования, масштабируемость, инструментарий — все это те области, в которых он должен стать лучшим средством для устранения неполадок и выявления проблем.

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

Site Reliability Engineer фактически не должен исправлять ошибки в сервисах, но он может это сделать и также объяснить ответственному сотруднику, в чем же именно проблема.

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

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

Являются ли SRE уникальными людьми по вызову?

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

SRE, кроме того, что являются частью этой ротации — это лица, ответственные за MTTR (среднее время восстановления) и количество ложноположительных результатов. Инженер по надежности сайта должен быть в состоянии сделать MTTR как можно короче, а количество ложных сигналов — как можно меньше. Он должен улучшить мониторинг, инструментарий и простоту отладки сервиса.

Нужны ли SRE в каждой сервисной команде или если да, то сколько?

Сложно сказать в цифрах, но у SRE должна быть структура, которая дала бы им возможность проводить время вместе и видеть друг друга как единую команду, а также делиться знаниями и избегать использования слишком большого количества технологий в компании. Тем более, если это предприятие не в гигантских масштабах с точки зрения количества людей. Количество SRE на команду зависит от того, насколько это важно сейчас, на каком уровне находится комплексная надежность обслуживания и сколько уже человек вовлечено в работу над ней. Вы можете также выбрать SRE на аутсорсе и точно не прогадать.

Попробовать воспользоваться услугами Site Reliability Engineer – это то, что порой поможет выйти из тупика и пересмотреть множество внутренних процессов на предприятии. Помните, что SRE не заменяет вашу оперативную команду, но послужить ключевым звеном во многих вопросах ИТ для компании они точно смогут