Заявка на услуги DST
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Именно SRE-инженер находится в первых рядах, если речь идет про обеспечение аптайма высоконагруженных сервисов и стабилизацию системы после краша. Именно поэтому такой специалист должен разбираться и в разработке, и в системном администрировании, и в траблшутинге. Но есть еще одно чрезвычайно важное умение для SRE-инженера: работа с БД & облачной инфраструктурой. Остановимся на этом чуть подробнее.
Умение работать с базами данных и облачной инфраструктурой -- основа основ в SRE. К тому же, следует учесть, что сегодня очень многие компании переводят инфраструктуру в облако — и дело не только и не столько в том, что это модно и в тренде. Процесс является закономерным, поэтому SRE-специалист должен быть готов к миграции БД из MySQL в Azure либо AWS, соответственно, он может столкнуться с необходимостью:
- настройки бэкапов,
- оптимизации запросов,
- написания собственных инструментов,
- выставления лимитов,
- обкатывания БД на стенде,
- тестирования и развертывания всего этого добра в production.
Что будет плюсом?
Будет здорово, если SRE-инженер умеет:
- работать с Microsoft Azure на уровне разработчика;
- работать в Azure Data Explorer;
- работать с системой управления идентификацией и доступом, уметь ее автоматизировать;
- работать с Azure REST API;
- управлять инфраструктурой с помощью Azure CLI (посредством интерфейса командной строки).
Что-нибудь еще?
Да, да и еще раз да. Будет вообще прекрасно, если SRE-специалист знаком с формированием политик RBAC (Role Based Access Control — управление доступом на основе ролей). Подход представляет собой альтернативу спискам ACL, его суть - создание ролей, которые повторяют бизнес-роли в компании и присваивают их пользователям. На основе таких ролей можно проверить, может ли пользователь выполнить то либо иное действия.
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Ижевск, ул. Воткинское шоссе, д. 170 Е, Технопарк Нобель, офис 1117
Задать вопрос по почте
Если выкинуть модное слово SRE и немного вернуться и поговорить о DevOps подходе (а не человеке), то фактически DevOps — это настойщий полный фул-стек.
С одной стороны — делается продукт, с другой — этот продукт с помощью определенных инструментов катится в прод к клиенту и обратная связь появляется маскимально быстро, модификации идут более точно т.к. часть можно решить инфрой, часть — через изменения продукта и т.д.
Мотивация этого действа полностью бизнесовая. А базовая необходимость в том, что современная инфрастуктура может быть на порядки сложнее большинства приложений, что на ней работают и без общего понимания всего хотя бы на среднем уровне получаются плохо работающие приложения, велосипеды, перерасход ресурсов на поддержку и т.д.
А еще это интересно и хайпово просто:)
Короче одно другому не мешает, проблема только в том, что программистов, умеющих в девопс мало. Очень мало. Как и «девопсов» умеющих в архитектуру и программирование. И даже если их собрать в одной команде, придется еще и все процессы перестроить, а для этого надо очень хорошо знать что ты делаешь, что опять же проблема, потому что найти такого лида тоже сложно и т.д.
Поэтому часто идут перекосы и нормальный процесс превращается в то, что все занимаются не своим делом, но под новой вывеской.