Блог CEO, CIO Виктора Карабедянц Блог CEO, CIO Виктора Карабедянц
  • Обо мне
  • Навыки
  • Образование
  • Опыт
  • Проекты
  • Блог
  • CIO аутсорсинг
  • Контакты

Кто такой и когда вам нужен Site Reliability Engineer?

23 августа 201923 августа 2019 / By Виктор
  • Home
  • Кто такой и когда вам нужен Site Reliability Engineer?

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

  • Недостатком знаний о том, что же означает роль 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

Виктор

Leave a Comment

Cancel Reply

*Please complete all fields correctly

В блоге представлены не только мои материалы, я делаю композицию из разных материалов, а так же размещаю переводы интересных тем.

Категории
  • DevOps
  • Без рубрики
  • ИТ поддержка
  • Руководитель ИТ
Популярные статьи
  • Основы DevOps. Вхождение в проект с нуляЧетверг - 16 января, 2020
  • Делегирование как инструмент руководителя – личные советыПятница - 20 декабря, 2019
  • Преимущества и недостатки слияний компанийПятница - 13 декабря, 2019
  • Особенности работы data driven компанииПятница - 15 ноября, 2019
  • ТОП рекомендаций по развертыванию программных средств бизнес-аналитикиПятница - 01 ноября, 2019
Tags
CIO DevOps service desk Безопасность ИТ директор ИТ менеджер Удаленный ИТ директор контейнеры
Комментарии
  • Поиск доступности в облаке Воскресенье - января 24, 2021 10:15 пп
  • Selenium, Selenoid, Selenide, Selendroid – что все это значит Суббота - января 23, 2021 03:55 пп
  • Работа удаленно: чего ожидать и как себя подготовить Пятница - января 22, 2021 08:58 дп
  • Показатели KPI для информационной безопасности Пятница - января 22, 2021 08:15 дп
  • ТОП рекомендаций по развертыванию программных средств бизнес-аналитики Пятница - января 22, 2021 03:00 дп
© 2017 - 2019 Виктор Карабедянц