Заявка на услуги DST
Наш специалист свяжется с вами, обсудит оптимальную стратегию сотрудничества,
поможет сформировать бизнес требования и рассчитает стоимость услуг.
Работа с базами данных и облачной инфраструктурой в SRE
Именно SRE-инженер находится в первых рядах, если речь идет про обеспечение аптайма высоконагруженных сервисов и стабилизацию системы после краша. Именно поэтому такой специалист должен разбираться и в разработке, и в системном администрировании, и в траблшутинге. Но есть еще одно чрезвычайно важное умение для SRE-инженера: работа с БД & облачной инфраструктурой. Остановимся на этом чуть подробнее.
Умение работать с базами данных и облачной инфраструктурой -- основа основ в SRE. К тому же, следует учесть, что сегодня очень многие компании переводят инфраструктуру в облако — и дело не только и не столько в том, что это модно и в тренде.
- настройки бэкапов,
- оптимизации запросов,
- написания собственных инструментов,
- выставления лимитов,
- обкатывания БД на стенде,
- тестирования и развертывания всего этого добра в production.
Что будет плюсом?
Будет здорово, если SRE-инженер умеет:
- работать с Microsoft Azure на уровне разработчика;
- работать в Azure Data Explorer;
- работать с системой управления идентификацией и доступом, уметь ее автоматизировать;
- работать с Azure REST API;
- управлять инфраструктурой с помощью Azure CLI (посредством интерфейса командной строки).
Что-нибудь еще?
Да, да и еще раз да. Будет вообще прекрасно, если SRE-специалист знаком с формированием политик RBAC (Role Based Access Control — управление доступом на основе ролей). Подход представляет собой альтернативу спискам ACL, его суть - создание ролей, которые повторяют бизнес-роли в компании и присваивают их пользователям. На основе таких ролей можно проверить, может ли пользователь выполнить то либо иное действия.
Работа с базами данных и облачной инфраструктурой в SRE
Напишите нам прямо сейчас, наши специалисты расскажут об услугах и ответят на все ваши вопросы.
Комментарии и отзывы экспертов
Вам может быть интересно
В этой статье разработчики компании DST Global обсудят ускорение и масштаб в СУБД, две фундаментальные концепции из параллельной обработки для баз данных, которые используются для настройки баз дан...
Тестирование — это сквозная проблема; Как и базы данныхОчень важно последо...
Двоичное квантование в векторных базах данных повы...
В этой статье вы узнаете от разработчиков компании...
Узнайте о преимуществах от разработчиков компании ...
Oracle — самая популярная база данных в мире...
Повысьте производительность и масштабируемость, ис...
В этом комплексном сравнении от разработчиков комп...
: создание эффективных практик разработки и обслуж...
В этой статье рассматривается, что такое потоковая...
Новые комментарии
Сегодня специалисты разных сфер внедряют LLM в свои повседневные задачи. С их по...
Параметры LLM можно сравнить с нейронными связями: чем их больше, тем “умнее” мо...
Насколько понимаю самые популярные опенсорсные модели сегодня: — GPT-J: ра...
Если выкинуть модное слово SRE и немного вернуться и поговорить о DevOps подходе (а не человеке), то фактически DevOps — это настойщий полный фул-стек.
С одной стороны — делается продукт, с другой — этот продукт с помощью определенных инструментов катится в прод к клиенту и обратная связь появляется маскимально быстро, модификации идут более точно т.к. часть можно решить инфрой, часть — через изменения продукта и т.д.
Мотивация этого действа полностью бизнесовая. А базовая необходимость в том, что современная инфрастуктура может быть на порядки сложнее большинства приложений, что на ней работают и без общего понимания всего хотя бы на среднем уровне получаются плохо работающие приложения, велосипеды, перерасход ресурсов на поддержку и т.д.
А еще это интересно и хайпово просто:)
Короче одно другому не мешает, проблема только в том, что программистов, умеющих в девопс мало. Очень мало. Как и «девопсов» умеющих в архитектуру и программирование. И даже если их собрать в одной команде, придется еще и все процессы перестроить, а для этого надо очень хорошо знать что ты делаешь, что опять же проблема, потому что найти такого лида тоже сложно и т.д.
Поэтому часто идут перекосы и нормальный процесс превращается в то, что все занимаются не своим делом, но под новой вывеской.
Предположим, что в пятницу у сервиса два важных события: вечером выходит финальный эпизод сериала «Игры у стола» и тем же вечером разработчики апдейтят бэк. Тесты проходят, всё работает, «Игры» летят — разработчики уходят в бар отмечать долгожданный релиз. А в субботу утром десятки тысяч людей не могут нормально посмотреть сериал: вместо 20 мс сайт работает с задержкой 100500 мс.
При традиционном подходе к надёжности первыми о ситуации узнают сотрудники поддержки, ведь расстроенные зрители заполнят все чаты. Специалист поддержки не может восстановить работу сервиса — он эскалирует проблему, передав её в технический хелп. Там увидят, что случилась большая беда, и начнут вызванивать разработчиков. Не факт, что все они на связи в субботу, ведь у всех нас есть свои дела по выходным. В итоге через несколько часов соберётся консилиум программистов и будет решать, что делать: откатывать апдейт или попытаться пофиксить текущий билд. На восстановление нормальной работоспособности уйдут часы или даже дни — а такой простой очень дорого обходится бизнесу.
В компаниях с командой из 10–15 человек можно обойтись без SRE: обычно разработчики дежурят по очереди. А вот большому высоконагруженному сервису, например банку, без такого специалиста не обойтись: в случае проблем счёт идёт на минуты.
Но обычного письма или пуша для SRE-инженера мало. Алерт в его случае работает многоступенчато. Например, сперва разработчик получает уведомление через телеграм-бота. После этого он должен быстро отметить в мониторинговой админке, что увидел проблему. Если этого не сделать, мониторинг начнёт звонить SRE-специалисту по телефону, вызывая на бой с багами. Многоступенчатость важна, ведь сервис может упасть и ночью, а во сне можно случайно пропустить вызов или машинально отменить его, как будильник.
В небольших и средних компаниях обычно дежурит один SRE-инженер. Если он пропустит алерт, то решение ситуации придётся откладывать. В больших компаниях инженеров сразу несколько — они могут подстраховать друг друга.
Чтобы работать очень быстро, в SRE используют парадигму «инфраструктура как код». Инженеры могут управлять инфраструктурой и настраивать её через процедуры в коде — так они работают со всеми компонентами в одной среде и не отвлекаются на ручное «накликивание» настроек серверов.
Чтобы SRE-инженер хорошо знал свой продукт, он часто участвует в его разработке. Как правило, это очень опытный, сильный программист, вожак стаи с самыми мощными лапищами. Иначе команда просто не будет ему доверять.
Бюджет ошибки. SRE-команды считают так называемый бюджет ошибки — допустимый период, в течение которого сервис может работать ниже целевых уровней. С помощью бюджета можно измерять серьёзность инцидентов. Если, например, инцидент истратил 30% бюджета, его можно считать серьёзным. Это помогает SRE-инженерам не отвлекаться на минорные проблемы, которые регулярно возникают даже в самых оттестированных проектах.
Постмортемы. Это грустное слово означает отчёт или небольшую статью, которую пишут по результатам решения проблемы. С помощью постмортемов SRE-инженер делится важным знанием с командами разработки, помогая избежать ошибок в будущих проектах.