Что я узнал за 7+ лет работы DevOps'ом
В небольшой компании по разработке ПО, заказчиками которого является среднего размера компании в США/Европе.
Вакансия DevOps чаще всего содержит требования к целому отделу:
Network engineer/SysOps/DevOps/SRE/Information Security Officer. Всем понятно, что за одну заработную плату.Если один DevOps специалист выполнит задачу за 4 часа, то два выполнят её уже за 8, а три - за 24 часа.
Чтение документации любого облачного сервиса следует начинать с ограничений данного сервиса. Вероятно дальше читать не придётся.
Если ты написал хоть строку в пайплане и она не связана с продом, но прод после этого упал (даже через месяц) - тебя будут пытаться обвинить.
Релиз в пятницу до обеда + один sick day, после обеда + два.
Best practices - удел больших компаний с выставленной методологий и процессами. Чаще всего они адаптирутся под реалии бизнеса и разработки. Чаще в сторону ухудшения.
Программист и разработчик - два разных человека. Первый пишет код за оплату и идёт гулять, второй пытается разобраться в хотелках бизнеса и решить их оптимальным образом.
Разработчики ПО слабо разбираются в сетях.
Бизнес всегда хочет думать что ему нужен высоконагруженная и отказоустойчивая инфраструктура с SLA . До момента рассчётов стоимости, после бизнес согласен на предложенные оптимальные варианты.
Через год эксплуатации инфраструктуры из п.9 расходы урежут на 40%.
Вы и ваш коллега из другой компании, спланируете инфраструктуру проекта абсолютно по-разному.
Пайплайн, поддерживающий обратные зависимости, запущенные дважды может выдать разный результат.
Современные технологические решение и инструменты внедряются, почти всегда, в небольших продуктах. Крупные компании чхали на требования рынка и будут жить при имеющихся технологиях пока их не покарает регулятор. (К примеру федеральная платёжная система, с SOAP API под http, в 2к25. Браго, их, хотя бы по белому списку работают).
Любой документ с планом проекта/работ нужно дать посмотреть непрофильному коллеге почти всегда найдёт что-то, что вы упустили.
SLA 95, без собственного ЦОДа - утопия.
Мониторинга много бывает.
Если решение, которое было принято в проекте который вам достался, очень странное и неуместное есть разные варианты:
У вашего предшественника было мало времени
У вашего предшественника было мало бюджета
У вашего предшественника было мало знаний
Вашего предшественник немного странный.Поднять ПРОД после падения, не равно его починить.
Сложно принять, но DevOps - обслуживающий персонал разработчиков, а они в свою очередь - бизнеса.
"Старайся всё делать хорошо, говно само получиться".
Всем коллегам зелёных пайплайнов, успешных релизов и только ложных алертов.
