В прошлом посте я рассказал про плюсы работы 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/

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

Не все йогурты одинаково полезны

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

Как многие уже знают, обещать - не значит жениться.

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

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

Что бы я отмел сразу: курсы типа "профессия DevOps". Это не профессия, это набор материала, который может пригодиться в этой профессии. Поэтому имеет смысл сформировать свой план изучения и искать курсы, которые "не профессия", а "навык".

Для этого даже ходить далеко не надо: есть Devops Roadmap, который является готовым планом развития и освоения девопс.
А также курсы по куберу (аж два, для разных уровней), терраформу и докеру.

Еще важный момент, на который стоит обратить внимание - формат курса.

Если много видео и теории и мало практики - толку тоже мало. В приведенных выше курсах 93.5% практики и необходимая теория.

☝️Суть тут в том, что вы так или иначе эту теорию все равно освоите, но через свой опыт, что многократно ценнее и лучше запомниться, чем просмотр очередного видосика.

На днях вышел Kubernetes 1.29 "Mandala", который будет поддерживаться до 28.02.25.

Среди новшеств можно выделить следующие:

◽️ sidecar container достиг состояния беты и включен по умолчанию. Напомню, что это новый тип контейнеров, который не блочит остановку пода, помогает собирать логи и много другое.

◽️ Precision Image Pulling - возможность задать runtimeClassName для того чтобы влиять на то из какого registry доставать образ.

◽️ ReadWriteOncePod - новый режим, если доступ нужно ограничить единственным подом на одном узле. Существующий режим ReadWriteOnce (RWO) ограничивает доступ к узлу, однако можно читать из нескольких подов на данном узле.

◽️ Новый бекенд для kube-proxy на базе nftables вместо устаревающего iptables.

◽️ Kubectl drain helper callbacks - возможность создать свой скрипт, который будет исполняться в разные моменты операции drain на ноде, таким образом можно контроллировать процесс очистки ноды, включая различные уведомления.

◽️Добавлены новые метрики (CPU utilization, Use of ephemeral storage, bandwidth of each node).

→ Это основные изменения, остальное можно изучить в release notes.

👾 Напомню, что существуют два курса по kubernetes от Devopstrain.

Сегодня я хотел бы поговорить об операционных системах, на которых лучше всего готовить Девопс.

Я давно уже вынашивал эти мысли, но раньше у меня не было канала, где я бы мог их изложить, а теперь - есть 😎.

Собственно, о чем речь: речь о главном инструменте devops инженера - его компе. Да, в любом деле главное - подходящий инструмент и умение им пользоваться. Комп сам по себе - железка, важно на чем он работает.

🐧 Как известно, в мире devops самой востребованной системой является Linux (различные его варианты). В моем roadmap он даже идет первым пунктом. Впрочем, и в остальном мире Linux - это самая популярная ОС (Андроид работает на базе Linux ядра).

👾 Раз уж devops инженер работает с серверами на Linux, то почему бы ему не использовать эту же систему в качестве основной десктопной при работе? Это очень удобно, т.к. по сути вы не меняете контекст, что тут linux, что на том конце. Все команды уже на автоматизме работают, из головы не вылетают.

Конечно, MacOS тоже unix-подобная ОС, но все же это совсем другая песня, и несмотря на то, что это сильно лучше, чем Windows, все равно я крайне рекомендую использовать Linux в качестве основной. Встречались правда люди, которые неплохо девопсят и с windows, но это скорее исключение и явно антнипаттерн, несмотря на наличие WSL, который был жалкой попыткой остановить отток разработчиков и прочих технарей с винды.

Сам я с года 2001 уже винду не использовал, вместо этого открыл дивный мир Linux, который не перестает меня радовать до сих пор. Что уж говорить, сейчас и 20 лет назад это совершенно разный экспириенс, стало сильно меньше страданий, хотя по юности это скорее воспринималось как очередной челендж. Вообщем - рекомендую!

Давайте подведем итоги 2023 года, как обычно принято делать в конце декабря.

👽 В devops сфере не произошло каких то серьезных изменений, однако, по моим ощущениям, тренд по его внедрению продолжает усиливаться. Как следствие, больше компаний внедряют Kubernetes (какой без него девопс?) и прочую автоматизацию.

➜ В зависимости от специфики и локации компаний, требования разные, и способ развертывания k8s кластера свой: кому-то нужно обязательно свой кластер на своем железе, а кому то и облачного за глаза. В связи с развитием искусственного интеллекта все больше внедряется MLOPS.

💪 Что по итогам года платформы Devopstrain (небольшая копипаста из недавней рассылки):

👾 В марте платформа devopstrain была по сути перезапущена после 2 лет паузы
👾 В то же время был доработан курс "Kubernetes на практике"
👾 Был обновлен основной сайт, запущен блог
👾 Был создан Kurator - open-source инструмент для автоматической проверки заданий на localhost (для terraform и docker курсов) - об этом можно написать отдельный пост, очень крутая штука.
👾 В сентябре был сделан курс "Terraform на практике"
👾 В октябре стал доступен курс "Docker на практике"
👾 В ноябре вышел в продажу курс "Kubernetes advanced"
👾 Примерно тогда же появился ставший хитом мета-курс "Devops roadmap"

🌲 С наступающими праздниками, пожеланием успехов в работе и удачных деплоев в будущем году!

Когда все выпито, и оливье доеден, захотелось порассуждать на злободневную тему - ИИ (AI), то есть про искусственный интеллект и как он может коснуться нашей с вами работы в DevOps.

▪️Прошлый год, очевидно стал наиболее значимым для AI сферы: множество обычных людей и компаний не только попробовали его использовать, но и плотно подсели на такие вещи как ChatGPT и Midjourney.
Безусловно, мир уже не будет прежним, потому что ИИ реально помогает делать работу. Рутину вообще прекрасно можно поручить AI.

🤨 Но на лицо также прогресс в качестве результата от генеративных моделей. Что, безусловно не может не пугать: что если меня заменит бездушная железка, а мне придется выращивать помидоры в Сибири?
Пока опасения могут показаться преждевременными, но по моему мнению, уже сейчас пора задуматься над таким сценарием, т.к. сокращения разработчиков и разных копирайтеров это уже реальность, не без участия AI.

👾 Позитивная сторона: devops - это то глубокая интеграция в разработку и эксплуатацию, что затрудняет внедрение AI, по крайней мере в ближайшие годы, а возможно и не очень ближайшие. Потому что доверить доступы и проведение ответственных операций неподконтрольной нейросети - это безумие.
Даже если нейросеть под вашим контролем, все равно цена ошибки слишком высока, и явно выше зарплаты devops, с которого можно спросить, если что.

◽️Другое дело разработка, там не требуются доступы, рутинный код уже может быть сгенерирован через chatGPT, и получается, что джуны уже остались не у дел. Отсюда я прогнозирую скорую переквалификацию разработчиков в другие сферы, в частности в DevOps, что приведет к большей конкуренции в данной области.

➟ Поэтому, рекомендую не откладывать обучение в долгий ящик, AI наступает на пятки, хоть и через разрабов. Если что, курсы Devopstrain как раз заточены на быстрое освоение наиболее важных тем в devops 🫡.