Начнем, пожалуй, с того, что принято называть DevOps.

Понятно, что девопсами в обиходе называют неких специалистов, которые занимаются DevOps =) Так что же это такое? Поискав, вы скорее найдете такое определение, либо очень похожее:

"Devops - это набор практик, а не какой-то человек. Это регулярные и частые улучшения, которые происходят через изменения процессов, а эти изменения в свою очередь можно измерить с точки зрения как внутренних результатов, так и выгоды для бизнеса в целом."

Давайте разберем более детально: само слово DevOps происходит от Development & Operations. Таким образом, разработка в данном случае неразразрывно связана с операциями, то есть с эксплуатацией ПО.

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

Чего и для чего измерять, и как это делать?

Измерить можно (список, конечно, не полный):

〰️ Количество новых фич за единицу времени
〰️ Количество запросов в приложение и на сколько они успешны
〰️ Увеличение клиентов
〰️ Увеличение чека
〰️ Сокращение расходов на обслуживание и снижение стоимости оборудования

Нет единого сценария внедрения практик DevOps для любой организации.
☝️В этом и состоит одна из задач: найти подходы, которые работают в данной компании, учитывая реалии и потребности.

Почему всерьез стоит рассмотреть профессию devops-инженера?

👽 За время своей довольно долгой работы в IT я повидал разного, работал на разных позициях и ролях: от разработчика до CTO. В итоге я остановился на позиции DevOps, и сейчас расскажу почему.

Это интересно

▫️Во времена когда были только разработчики и только "админы", многим казалось что быть админом, который просто установит пакет, который ему дали разработчики на голое железо - это скучно. Отчасти, может, и так, но те времена давно прошли, и теперь все немного сложнее. Админ теперь должен уметь больше, чем просто установить пакет. Да и установка уже должна быть автоматизирована через CI/CD. А уж сколько модных и нужных инструментов появилось для решения этих задач! Разобраться в этом всем многообразии бывает не просто, но уж точно интересно. Кто-то скажет: "Деды наши жили без ваших куберов и мы как нибудь проживем!". Бесспорно, но, боюсь, что даже деды уже посматривают на докер и кубер.

Это выгодно

▫️Зарплаты DevOps/SRE инженеров в среднем выше, чем у большинства разработчиков по нескольким причинам:

- Универсальные навыки: DevOps инженеры обычно обладают широким спектром навыков, включая знания в области разработки, системного администрирования, автоматизации, контейнеризации и управления инфраструктурой.
- Сложность работы: DevOps инженеры обычно занимаются созданием и поддержкой высокомасштабируемых систем
- Важность для бизнеса: DevOps инженеры играют ключевую роль в обеспечении непрерывной поставки программного обеспечения и эффективного управления инфраструктурой.
- Растущий спрос: Сейчас роль DevOps инженера становится все более популярной и востребованной.
- Ответственность и риски: Работа DevOps инженера связана с большой отвественностью и рисками. Они отвечают за стабильность и безопасность системы, а также за непрерывную поставку программного обеспечения.

Это надежно

▫️В кризисные для компании ситуации из всех технических специалистов devops инженеров скорее всего сократят позже остальных, по очевидным причинам. Если разработку можно свернуть без существенных проблем, то поддержку работоспособности самого продукта просто так не свернешь. Работы у девопс инженера станет меньше 😎, но полностью увольнять его не станут до закрытия компании или направления.

Так что, если думали над сменой профессии или направления в сторону DevOps - не зря. Ну а я помогу оценить ваши навыки, перспективы и следующие шаги на консультации.

В прошлом посте я рассказал про плюсы работы devops инженером. Но какие плюсы без минусов?

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

👾 Непрерывное обучение и обновление навыков:
DevOps инженеры должны постоянно обновлять свои навыки и следить за новыми технологиями и инструментами. Впрочем это касается всех IT спецов.

👾 Риск ошибок и проблем:
DevOps инженеры несут ответственность за стабильность и безопасность системы. Ошибки или проблемы в конфигурации или развертывании могут привести к сбоям или нарушению работы системы. Это может иметь серьезные последствия для работы бизнеса, включая потерю дохода, потерю клиентов и повреждение репутации компании.

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

Как запустить приложение?

Запустить - это значит обеспечить доступность в определенных рамках, как временных, так и в рамках поступающей на него нагрузки.

👽 Ой, сколько сейчас есть вариантов, от обычного shared хостинга до serverless.
Зависит, конечно от приложения и от того, что требуется для работы приложения, какие у него зависимости и какая ожидается нагрузка. Вариант с shared хостингом из начала 2000-х я не буду рассматривать, это к теме канала не относится.

* Dedicated server - он же железный или bare-metal сервер.
* Virtual Machine (VM) - она же виртуальный сервер
* Docker (или иной инструмент с container runtime) - система управления контейнерами, которая может быть запущена как на VM, так и на bare-metal
* Kubernetes - Сложная система оркестрации контейнейзированых приложений с большой экосистемой
* Serverless - запуск приложения из исходного кода на поддерживаемых языках

◽️Каждый из этих вариантов имеет множество реализаций и нижележащих технологий. К примеру, виртуальная машина может быть запущена на голом железе, либо в облаке, которое в свою очередь может быть публичным или приватным. Docker можно запустить внутри VM, либо сразу на bare-metal. Это же касается и kubernetes. Вариаций много, и конечно, важно понимать какие есть плюсы, минусы и ограчения выбранного пути. В рамках одного поста не получится рассмотреть, но я планирую регулярно рассказывать обо всех тонкостях, по возможности самым доступным способом.

☝️При поиске работы, в том числе на позиции devops инженера, нужно помнить, что не только сама компания отбирает кандидатов, но и вы выбираете компании. Чтобы выбор был более осознанный, я решил сделать короткий обзор типов компаний, с которыми мне приходилось иметь дело в той или иной степени.

👾 Стартап. Начало.

Характеристики:

- Нет налаженных процессов, коммитим сразу в мастер, тестируем в продакшене
- Задачи ставим в чате или почте
- Легаси тоже, впрочем, нет. Что позволяет начать сразу с самых актуальных технологий
- Можно творить как душе угодно
- Приложение крутится на виртуалке, без всякой стратегии "а если она упадет"
- Зарплата как правило ниже рынка, возможны задержки. Обещание опционов/захватить мир.

👾👾 Стартап. Год спустя

Если выжил (что уже хорошо), то характерно:

- Зачатки процессов, задачи уже ставим в Жире, используем ветки в git, code review для особо успешных проектов
- Документацию еще пока не пишем, надо захватить мир сначала
- От легаси еще не страдаем, всего год прошел, но обновлять компоненты "пока рано"
- Т.к. единственный сервер уже пару раз падал, появились мысли сделать второй сервер и поставить обоих за Load Balancer
- Зарплата уже ближе к рыночной, но все еще ниже. Пока только первый раунд подняли

👾👾👾 Стартап. 3 года спустя

- Работаем по спринтам, все задачи планируем, все как мы "любим"
- Документацию уже пишем, т.к. пару ключевых сотрудников ушли вместе со своей экспертизой и даже доступами. Было больно.
- Легаси еще не беспокоит, но ОС/пакеты уже обновили
- Запилили CI/CD для деплоя в продакшн и тестовые стенды
- Посматриваем в сторону Kubernetes, виртуалки с нашими микросервисами уже не справляются
- Зарплата рыночная, иногда может быть чуть выше, вероятно есть доп плюшки вроде ДМС

👾👾👾👾 Компания 500+ сотрудников

- Все по-корпоративному, но еще есть место для творчества
- Легаси уже накопилось, думаем что с ним делать, возможно придется выкинуть и заново переписать на модном Rust
- Все ресурсы в облаках, кубер настроен, и не один, gitlab ci, пайплайны, все дела
- Много созвонов: планнинг, грумминг, ретро, дейлики
- Зарплата рыночная + плюшки
- У ключевых devops инженеров есть дежурства, на случай факапа
- Для устройства может хватить 1 технического интервью, иногда бывают тестовые задания

👾👾👾👾👾 Компания 5000+ сотрудников

- Все по-корпоративному до жути, процессы неповоротливые как слон
- Зарплата может порадовать, но с вас три шкуры сдерут
- Есть выделенная команда мониторинга для реагирования на аварии
- Уже много использует своего железа вдобавок к облаку, из-за особенностей бизнеса и политики безопасноcти
- Для устройства потребуется 1 созвон с HR + 2 и более тех. итервью в том числе с практикой по алгоритмам (да, даже для девопс) и архитектурой
- Остальное все как у 500+

👽 Кидайте в комменты тип компании, в котором работали/хотели бы работать

Наиболее частый запрос, с которым приходят ко мне на консультации - это помощь в определении пути профессионального развития как Devops инженера.

Конечно, я с этим помогаю в процессе разбора имеющихся навыков и стремлений. Интересно, что в процессе выясняется что человек хочет немного иного, после того как узнает подробности. ☝️В devops ведут много путей, и каждый выбирает свой.

💪 Чтобы помочь на начальном этапе определиться с выбором я подготовил бесплатный мета-курс Devops Roadmap, представляющий собой расширенный чек-лист, который поможет вам сориентироваться в мире DevOps.

👀 В нем перечислены все основные разделы и навыки, которыми должен обладать DevOps инженер: от Linux до программирования. А еще он будет полезен при подготовке к собеседованиям.

👾 Заходите, регистрируйтесь и двигайтесь в своем режиме

Почему программирование - важный скилл для девопса

🤓 Кажется, что почти все можно решить уже имеющимися инструментами и средствами, достаточно лишь подправить конфиг под требуемую задачу. Однако, на практике это не всегда возможно, и не всегда проще, чем написать несколько строк на каком-либо языке программирования.

☝️Не стоит бояться написать простую программу, которая будет делать именно то что вам нужно, при этом вам не понадобится строить костыли из конфигов и дополнительных прослоек, которые явно не способствуют упрощению и делают конструкцию шаткой. Помните, что вам на помощь придут готовые библиотеки, и конечно chatGPT =)

Пример: вам необходимо экспортировать метрики в формате prometheus, но подходящего exporter не нашлось, либо он не выдает требуемые данные. Код на golang может выглядеть так:

package main
import (
"time"
"github.com/labstack/echo/v4"
"github.com/prometheus/client_golang/prometheus"
"github.com/prometheus/client_golang/prometheus/promhttp"
)

var (
counter = prometheus.NewCounterVec(prometheus.CounterOpts{
Name: "stand_counter",
Help: "Total stands",
}, []string{"stand"})
promRegistry = prometheus.NewRegistry()
)

func metricsHandler(c echo.Context) error {
// Serve the Prometheus metrics
h := promhttp.HandlerFor(promRegistry, promhttp.HandlerOpts{})
h.ServeHTTP(c.Response(), c.Request())
return nil
}

func main() {

promRegistry.MustRegister(counter)
e := echo.New()
go func(){
for {
time.Sleep(1 * time.Second)
counter.With(prometheus.Labels{"stand":"stand1"}).Add(1)
}
}()
e.GET("/metrics", metricsHandler)
e.Start(":8080")
}

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

👽 Но помните, что изобретать велосипед не нужно, и для стандартных задач используйте стандартные решения.

Самое интересное 👇

👾 Вот вам ссылочки на мой бестселлер - индивидуальное наставничество и курсы, с которыми у вас просто нет шансов не получить знания и навыки.

🤖 @devopstrain_mentoring_bot - ответит на все ваши вопросы 24x7

✔️ Проходите пробные уроки, практикуйтесь, там выбран интересный формат обучения - без видео, через практику. Однозначно не скучно.

💪 Так что, если хотели прокачать Kubernetes, Terraform, Docker, CI/CD, Linux получить опыт и навыки, которые можно добавить в резюме - welcome.

А в этом канале вас ждут:

〰️ свежие IT-новости (чтобы быть топ of the топ)
〰️ полезные советы от меня и что действительно важно в этом devops
〰️ эксклюзивные материалы
〰️ релизы (обновления) топовых инструментов, их фичи и баги
〰️ обзоры вакансий
〰️ личный взгляд на девопс-сферу

Ну и не стесняйтесь комментировать/спрашивать и познавать devops.

Итак, что у нас по вакансиям в сфере DevOps/SRE. Мониторю обстановку, и у меня сложился ряд наблюдений:

▪️ Рынок все же сейчас не наш, рынок сейчас работодателя, из этого вытекает, что требования достаточно высокие.

▪️ Но есть варианты и не только для сеньоров, мидлов вполне тоже могут взять. И даже джунов берут, иногда. Просто требования стали выше.

▪️ Фанатизм вроде "работать можно только из РФ" в случае российских компаний, субъективно пошел на спад, но зависит конечно.

▪️ Некоторые, не многие, но по-прежнему спрашивают алгоритмы на собесах, хотя мы вроде как не разработчики 👽.

▪️ Стек стал более похожим чем несколько лет назад, опять же субъективно. По сути roadmap, закрывает 90% требований 90% вакансий.

▪️ Сеньорская вилка довольно широкая, от 280 до 450 т.р. Но за 400+ хотят прям много всего. Скажем так, больше чем за $5К в западных компаниях, но с ними тоже есть нюансы.

▪️Наиболее часто встречающиеся сферы: финтех, банки, геймдев, е-коммерс и ритейл, а также интеграторы для таких компаний.

Вот такой обзор текущей ситуации, продолжаю мониторить и отбиваться от HR 👀, а как у вас дела с работой?


DevopsTrain

Senior YAML developer

В прошлом посте я написал, что мы, то есть девопсы - не разработчики.

👽 На самом деле это не совсем так, во-первых потому, что devops = development + operations, что как бы намекает на разработку. Я имел ввиду, что разработка - это не главное занятие девопс инженера, хотя читать и писать элементарный код надо уметь.

〰️ Во-вторых, нас в шутку называют Senior YAML developer, что только отчасти шутка, принимая во внимание, сколько yaml кода приходится писать: от манифестов для Kubernetes до плейбуков на Ansible. Да, выбирая современный девопс, вы невольно становитесь yaml "разработчиком", хотите или нет.

Поэтому, важно понимать все структуры языка и как они соотносятся с Json:
* скалярные типы (строки, int, float, boolean, null, datetime)
* списки (sequences)
* словари (mappings)
* блоки | и >
* разделение документов —-

Конечно, существуем масса других форматов конфигов: toml, ini, json, jsonnet, hcl, но yaml - самый популярный

DevopsTrain

Метрики Prometheus

В современном мире Devops, метрики формата Prometheus уже стали стандартом, который применяется для мониторинга приложений, а также для их масштабирования.

◽️Напомню, что архитектурно Прометей использует pull модель для получения данных, то есть сервер сам запрашивает с указанных точек метрики с заданным интервалом. Эти самые точки принято называть exporters. Существует великое множество готовых экспортеров на все случаи жизни.

👾 К примеру, мы хотим, мониторить redis на предмет длины очереди, которая не должна превышать заданного прога. Для этого можно запусть redis exporter, который будет связующим звеном между prometheus и сервером redis. А в его настройках укажем запрос, который нам необходим.

◽️Приложения, конечно, могут иметь и встроенные метрики, в этом случае промежуточное звено не требуется.

Prometheus определяет четыре основных типа метрик:

1. Counter: Счетчик представляет собой простую числовую метрику, которая только увеличивается или сбрасывается до нуля на перезапуске. Примеры счетчиков: количество запросов к HTTP-серверу, количество выполненных задач и т.д.

2. Gauge: Это метрика, которая представляет собой одиночное числовое значение, которое может произвольно увеличиваться или уменьшаться. Примеры: текущее использование памяти, количество одновременно работающих потоков и т.д.

3. Histogram: Гистограмма представляет собой метрику, которая собирает наблюдаемые значения в виде бакетов (группы значений в определенном диапазоне) и также обеспечивает счетчик накопленных наблюдений и сумму всех наблюдаемых значений. Примеры: измерение времени ответа, размер запроса и т.д.

4. Summary: Summary аналогичен гистограмме, но также предоставляет возможность вычисления квантилей наблюдаемых значений.

DevopsTrain

Недавно пришлось настраивать Grafana Agent Flow для отправки логов в Loki, и вот что интересно:

Читаю доку и вижу подобное:

logging {
level = "warn"
}

loki.relabel "gelf" {
forward_to = []
rule {
source_labels = ["__gelf_message_host"]
target_label = "host"
}
}

loki.source.gelf "listen" {
forward_to = [loki.process.extract.receiver]
relabel_rules = loki.relabel.gelf.rules
}
...

Был уверен, что это HCL - язык конфигурации Terraform, с которым многие из вас уже знакомы. Но нет, каждая уважающая себя компания должна создать свой язык конфигурации, который вдохновлен [чем-то] и лучше [тем-то].

Перед вами язык конфигурации River, очень похожий на HCL, но со своими особенностями. Например можно делать такие вещи:

env("HOME")

Прямо как в меме про 14 конкурирующих стандартов =)

👽 Если вы еще не знакомы с Terraform, то у меня есть свежий практический курс

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

Я к этому пришел уже давно, но далеко не сразу.

Хочу сэкономить вам время и рассказать об этом подробнее. Суть идеи в том, чтобы записывать в единое хранилище все ключевые вещи, которые кажутся вам полезными.

К примеру, вы наткнулись на проблему: не получается удалить некоторые PVC в Kubernetes. Либо хотите иметь в быстром доступе команду или список фактов о чем-либо. Как пример: особенности протокола TCP. Часто такие вещи требуются неоднократно, и это означает что каждый раз вам нужно найти решение в гугле → потратить на это время.

👾 При наличии локальной БД, вы быстро откроете нужную заметку. Конечно, с появлением GPT стало чуть проще, но это НЕ замена личной базы знаний.

◽️В качестве реализации можно использовать разные инструменты: Obsidian, Logseq, Notion, Roamresearch и т.д.

Но я, как любитель консоли, в итоге остановился на Emacs + Org-roam + MD-roam.

😎 В итоге, одним из продуктов, основанных на моей базе знаний, стала образовательная платформа DevopsTrain, которая позволила упорядочить информацию наилучшим образом.
Вместо классического подхода с видео, я сосредоточился на практике с оптимальной дозой теории, взятой из моих записей, собранных в процессе многолетней работы.

До сих пор очень часто попадаются devops вакансии, где среди требований есть стек ELK(EFK) - Elasticsearch + Logstash + Kibana

👽 Осмелюсь выразить свое мнение на этот счет. Я конечно понимаю, что легаси нельзя просто так взять и заменить на что-то современное, но все же 23 год уже подходит к концу.

Нет, безусловно, у Elasticsearch есть свои преимущества, но если уже использовать его, то по моему мнению лучше взять для этого Graylog, это комплексный продукт, который умеет делать за вас многие ручные операции, включая ротацию индексов, запуск input'ов, и т.д.

👾А современный подход - это хранение данных в S3-хранилище, который обойдется вам в разы дешевле, чем огромный индекс логов в elasticsearch на диске.

◽️Речь идет про стек Grafana + Loki + (что-то, что пишет в локи, например Promtail/Grafana Agent), бонусом идет единый интерфейс Grafana для метрик, трейсов и логов.

Суть в том, что можно хранить дешево, а значит за долгий период. А скорость выборки зависит от количества реплик querier в составе Loki. Они просто разделяют работу по обработке данных между собой, то есть вы можете регулировать что для вас важнее, скорость или экономия.

💪 Все это я подробно разбираю на курсе Kubernetes Advanced, в разделе "Средства для логгирования".

DevopsTrain

Из backend-разработчика в DevOps: как так получилось

Когда-то давно, мне повезло работать в стартапе, и там я был одним из немногих разработчиков. Кодил бекенд на питоне (django). К слову, тогда еще не было такого богатого фронтенда, поэтому тебе давали просто html верстку страницы, и ты натягивал ее на бекенд, то есть страницы полностью генерились на сервере.

👽 На тот момент мне это было интересно, я прокачивал навыки, получал опыт. Но любое приложение должно быть где-то задеплоено, чтобы его увидел мир. Угадайте, кто этим занимался? Правильно, я. Приходилось настраивать сервера (физические!), а не вот эти ваши кубернетесы смузишные. Ладно еще, что арендованные, а не свои.

К чему я это? К тому, что начиная с начала 2000-х часто приходилось заниматься тем, что можно было отдаленно назвать DevOps.

👾 Поэтому когда стартап вырос до 10 разработчиков, а мне уже эта разработка порядком надоела, от меня было выдвинуто предложение:

"А давайте замутим нормальные девопс процессы и ускорим наши релизы, сделаем их более надежными и предсказуемыми! Я со своей стороны готов покинуть разработку" уж так и быть, кто-то же должен принять это непростое решение =)

~ Примерно в это же время на моем горизонте уже появился язык Golang, после которого я уже не возращался к разработке на Python, и надеюсь - не придется. А в devops процессах он очень даже помогает.

Вот так, тихо и не заметно я переключился в devops и, по правде говоря, обратно в разработку уже не тянет 👀.

DevopsTrain

Почему Makefile до сих пор актуален?

Немного истории: инструмент make и соответствующий ему Makefile были созданы в 1976 году в рамках проекта Bell Labs для Unix. В то время разработка софта становилась все более сложной, и возникла необходимость в автоматизации билдов из большого количества исходных файлов ➟ Makefile был создан как решение этой проблемы.

~ Основная идея состояла в том, чтобы определить "правила", которые описывают, как из исходных файлов получить конечный продукт (например исполняемый файл)

В Devops также часто используется Makefile не только для сборки софта, но и для удобного формата написания "скрипта".

К примеру, такой простой Makefile:

.PHONY: build push deploy
build:
  go build main.go
  docker build -t someimage:tag .
  rm main
push:
  docker push someimage
deploy:
  kubectl set image deployment.v1.apps/someapp container=someimage:tag

позволит вам обойтись без написания bash скрипта, при этом выглядит понятно и используется удобно:

make build && make push && make deploy

Сюда же можно добавить аргументы и их валидацию. Конечно, нельзя сказать, что это идеальное решение, но оно хорошо тем, что стандартное, ведь make есть везде, как vim. Говорят, есть более современное решение, но руки не доходят его опробовать - https://taskfile.dev/

Если вы уже пробовали - напишите в комментариях