Я начал работать инженером по надежности сайта довольно давно. За это время, прошел разные пути и окунулся во все процессы компаний, с которыми им приходится сталкиваться в поиске человека на подобную должность:
- Недостатком знаний о том, что же означает роль SRE в работе
- Адаптацией
- Ростом
- Повторной адаптацией
- И вновь повторением сначала.
Примите факт, что Вы являетесь SRE не потому, что заботитесь о надежности, все заботятся о надежности, а потому, что система слишком сложна для управления человеком, который также занимается другими делами.
Нет никаких различий с любым другим «первым нанятым» в компании. Даже первого менеджера проекта нанимают, когда человек, который выполнял эту работу, уже не может ее делать, потому что компании нужен кто-то, на 100% ориентированный на продукт.
Инженер по надежности сайта должен повысить надежность обслуживания. Видимость, наблюдаемость, ведение протоколирования, масштабируемость, инструментарий — все это те области, в которых он должен стать лучшим средством для устранения неполадок и выявления проблем.
Способность обнаружить проблему до того, как о ней сообщит клиент, повышает надежность системы во много раз и говорит о том, что SRE отлично справляется со своими задачами.
Site Reliability Engineer фактически не должен исправлять ошибки в сервисах, но он может это сделать и также объяснить ответственному сотруднику, в чем же именно проблема.
Поэтому, не всегда четко указанные в регламенте работ SRE навыки и умения, ими же и ограничиваются. Важно иметь на данной должности человека, который гибко и экспертно справится с любой задачей, и я в этом деле, к Вашим услугам.
По всем вышеуказанным причинам SRE знает, как кодить, и какой результат должен быть получен. Он всегда находится близко к команде, которая создает сервис и заботится о дизайне, пользовательском интерфейсе, развертывании, управлении.
Являются ли SRE уникальными людьми по вызову?
Очевидно нет. Трудно достичь масштаба, в котором вы можете управлять задачами только с помощью SRE, ведь каждый разработчик несет ответственность за код, который он создает. Если же вам удалось организовать ротацию для каждого департамента с разными людьми, то вся команда должны быть на связи.
SRE, кроме того, что являются частью этой ротации — это лица, ответственные за MTTR (среднее время восстановления) и количество ложноположительных результатов. Инженер по надежности сайта должен быть в состоянии сделать MTTR как можно короче, а количество ложных сигналов — как можно меньше. Он должен улучшить мониторинг, инструментарий и простоту отладки сервиса.
Нужны ли SRE в каждой сервисной команде или если да, то сколько?
Сложно сказать в цифрах, но у SRE должна быть структура, которая дала бы им возможность проводить время вместе и видеть друг друга как единую команду, а также делиться знаниями и избегать использования слишком большого количества технологий в компании. Тем более, если это предприятие не в гигантских масштабах с точки зрения количества людей. Количество SRE на команду зависит от того, насколько это важно сейчас, на каком уровне находится комплексная надежность обслуживания и сколько уже человек вовлечено в работу над ней. Вы можете также выбрать SRE на аутсорсе и точно не прогадать.
Попробовать воспользоваться услугами Site Reliability Engineer – это то, что порой поможет выйти из тупика и пересмотреть множество внутренних процессов на предприятии. Помните, что SRE не заменяет вашу оперативную команду, но послужить ключевым звеном во многих вопросах ИТ для компании они точно смогут
About The Author
Виктор