DevOps Conf 2023: какие доклады посмотреть
Сказ о том, как мы платформу в продукт превращали
Инфраструктурная платформа - это очень проблемная штука, которую я так до конца и не понимаю, как делать, чтобы все вокруг не капали на мозг, что она не покрывает все кейсы, что девопсы не хотят ничего менять и тд и тп. Особенно мне понравился пассаж про "как мы отличаем реальные проблемы от нескольких громких голосов" - это жиза - всегда найдутся люди, которые будут ныть даже про что-то объективно удобное, что стало стандартом индустрии. Банальнейший пример - для сисадмина кликопс более удобно, чем инфраструктура как код, так как требует (на поверхностный взгляд) меньше мозговых затрат.
17 точек потери эффективности при работе с базой знаний
База знаний в большинстве организаций ведётся на отъебись, к сожалению. Иногда без бутылки не разобраться. При этом существует масса стандартов, как сделать пиздато, но их всем впадлу читать, потому что база знаний воспринимается как что-то сбоку-припёку, и, мол, кому надо, тот разберётся.
Как управлять базой знаний и не сойти с ума (на примере Confluence)
Автоматизированное создание окружений для R&D-команд
Скорее всего, в этом докладе будет разъёбан подход "среда - это неймспейс в Кубернетесе", лично я считаю это паршивой практикой, потому что у вас продакшн кластер будет содержать не только продакшн сервисы, а всё подряд.
Декларативное управление конфигурацией узлов Kubernetes в масштабе
Здесь, похоже, будут рассматриваться какие-то крайне интересные кейсы управления нодами кубера, с которыми я ещё не имел дело; в основном я работал с просто нодами в менеджед решениях, а вот когда у тебя воркеры на своём железе плюс конские требования по ИБ - то тут уже, вероятно, приходится ебстись.
Разбираемся во внутренностях CI/CD Ozon, или Как мы получили единую CI/CD-систему?
Единый пайплайн для разработки - это самый настоящий пиздец, так как:
- он неимоверно сложный и огромный, потому что там 150 шагов с условиями и миллиард строчек на баше
- из-за того, что в нём сложно разобраться, команды разработки не могут понять, что надо подкрутить, и не могут задать правильный вопрос или выставить правильные требования платформенной команде, а поэтому норовят его форкнуть и мутировать
Здесь я вижу то же самое - консольная утилита, баш-скрипт и так далее. Мне интересно не столько то, как Озон это делают, сколько то, можно ли вообще выкинуть к хуям всё это говно поноса сложное и сделать качественный сиай и гитопс, даже если у тебя 500 команд разработки.
Как перестать быть YAML-разработчиком. Переходи на сторону CUE
YAML здорово меня затрахал, с ним очень неудобно работать, сколько бы ты плагинов не повесил на свою IDE. Если CUE превратит работу с YAML в что-то, поддерживающие примитивы казуальных ЯП, то нужно срочно брать и использовать.
Ваши админы за 10 лет так и не смогли стать девопсами. Разработчики смогли
Я со временем пришёл к простой истине: если вы не умеете писать более-менее чистый код на какой-нибудь платформе ЯП, то вы будете писать просто ужасный инфраструктурный код, который будет везде разный, всё будет повторяться и страшно мутировать, поддерживать этот понос будет очень больно, так как всё будет работать по принципу карточного домика. Бонусом будет то, что любое глобальное изменение (например, выполнение мер по ИБ) будет длиться бесконечно дохуища времени. Мне максимум что удавалось сделать - это построить хотя бы иерархически логичный IaC + некие практики по глобальному его пидорингу, и это исключило боль по поддержке и разбирательству - но не исключило очень долгое выполнение больших изменений.
Так вот - девопсы выросли из админов, а админы понятия не имеют, как писать код, потому что админы писали баш скрипты для себя. Прикладной же код нельзя писать для себя, потому что за это разработчика будут возить мордой об стол на всех ревью.
Terraform-код — в поисках Грааля
С терраформом вышеозначенная проблема цветёт в полную силу, так что надеюсь, что автор нашёл серебряную пулю и покажет крутое решение.
"Инфраструктура как код - новый баззворд" - ахаха новый, лет 10 уже как :)
KubeVirt: внутреннее устройство и сеть. Как достигнуть совершенства?
Хотите узнать, на кой хыр нужно управлять ВМ через кубер - посмотрите это. Мне кажется, что это очередная попытка засунуть всё в кубернетес манифесты, думаю, что получается хуёво.
Почему не работает SRE в Enterprise?
Здесь достаточно сказать, что в некоторых энтерпрайзах SRE - это обычные дежурные, которые ребутят серверы и заводят тикеты. Сами понимаете, насколько это не похоже на каноничное определение SRE от гугла.
Почему для SRE важно уметь читать код
Ну, я об этом говорю постоянно, а тут в аннотации доклада практически дан ответ - чтобы дебажить опенсорс инструменты. Читать чужой код - легче, чем писать хороший свой, но является пререквизитом для хорошего своего кода :)
OOP Pipeline As a Service: декомпозиция пайплайна на ООП-интерфейсы для лучшего переиспользования и поддержки
Тут опять про энтерпрайз-левел пайплайн и возможное решение проблемы как раз-таки без Консольных Утилит размером с MS-DOS и баш-скриптов. Выглядит как хорошая попытка абстрагировать сложность, выставив пользователю некие крутилки вместо выставления пользователю миллиона строк кода на баше, где он ещё должен разобрать, какую ему переменную и где надо выставить, чтоб всё пошло по тому пути, какой он хочет.
Локальная инфраструктура для разработки K8s-native ПО
Это тоже одна из труднорешаемых (трудно найти, кто б её решил) проблем при разработке клауд нейтив приложений. Подавляющее большинство разрабатывают так: они руками ставят кучу пакетов в свою систему, используя свои тулзы или скриптики, затем пишут код, который запускают прямо в ОС, и только потом этот упакованный в докер-образ код херово работает в кубернетесе, а дежурные девопс и сре инженеры разбираются, какого хуя в момент передеплоя сервиса наблюдается разъёбывающий рост 503 ошибок. Чтобы разработчик разрабатывал сразу нормально, ему нужен +- универсальный докерфайл для его платформы, а также докер-композ манифест, но задача усложняется, когда на машине разраба мало ресурсов, когда надо откуда-то подтягивать пароли и токены, и т.п. Моё мнение - будущее в этом плане за проектами типа Telepresence, чтоб разработчик вообще не трахал себе мозги всякими докер-композами. Но эту проблему вообще чаще заметают под ковёр, типа девопсы справятся.
DevOps — путь на социальное дно, или Пробиваем дно DevOps-колодца
Вангую, это будет бомба этой конференции. Девопсы действительно в огромном количестве случаев не ломают никакую стену между разработкой и эксплуатацией, а наоборот, строят самый настоящий частокол из правил (которые ещё и записаны хер знает где) вместо автоматизации и всяческих "API" для работы с их хозяйством. Обратная связь работает хуёво и по принципу "вас много а я одна". Причина в действительно большом объёме работ, хуёвой экспертизе в построении каких-либо сервисов и в разочаровании от профессии.