Ну штош. Последний рабочий день в этом году. “Случайности не случайны”, как говорилось в одном мультике. Казалось бы. Каков был шанс, что два человека встретятся в одной кальянной, запишут целую серию, начнут генерировать идеи. Удивительно, но бывает и такое. И в конце нового года, когда наконец все девопсы подводят итоги уборки хлопковых плантаций для больших белых господ, я пожелаю вам больше случайностей)
Нам предстоит немало работы. Грамотная осознанная критика - противовес, которого всегда не хватает любому сообществу. Мы будем расширять наши пиратские девопс съезды, для тех, кто хочет услышать идеи, критику, и размышления. Продолжим снимать ламповые эпизоды. В общем, харрр харррр харррр.
Be in touch, fly safe) Мистер С.

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

https://habr.com/ru/companies/oleg-bunin/articles/735032/
“Архитектор умер, да здравствует новый техлид”
Подмена понятий - бич IT. Определенно.Честно, в статье намешано все. Сразу. Архитектор не нужен, потому что есть фреймворки. Чукче не нужно думать, есть тимлид и техлид. Эти же ребята готовы подхватить роль архитектора. Но они не архитекторы, потому что сам архитектор сферический конь в вакууме, который мыслит кораблями из большого театра. Но все же он нужен большим компаниям.

Кто-нибудь…….дайте этому человеку пистолет. И подскажите, а когда мы научимся писать более просто и понятно?)
Не приплетая все и сразу, законы мура, психику в потоке и тд. Велком в комментарии, подскажите пожалуйста, забили ли уже гвоздь архитектору или нет. Даже интересно стало.

Ну что, ребятушки? Праздники прошли, нас поймали будни

Как вы могли заметить, конечно же, нас стало двое) Я, всегда ваш покорный слуга, и некий МистерС, который лупит глаголом по сердцам людей, не разбирая своих и чужих

Все так и останется, собственно. Простой маленький канал про счастливых девопсов мы хотим превратить в Большое Пиратское Медиа и "Счастливый девопс" будет как Счастливый Роджер на всем известном флаге 🏴‍☠️

Почему, блять, пиратское?
Мы пытаемся сломать восторженный тон как по отношению к профессии, так и к сложившейся культуре "хуяк-хуяк и в продакшен", которая прикрыта кучей ярких тряпок со словами девопс-манифеста на них

Вот потому и пиратское!

Так, а что по контенту?
Контента будет больше. Настроим контент-план и будем постить по расписанию. МистерС продолжит ебашить хомяков с хабра и прочих помоечек, ну а я просто буду делиться с вами своими мыслями, идеями и всем вот этим, что мы так любим.

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

Так что учимся новым форматам и работаем для вас, друзья! Ну что, поднимаем флаг "Счастливого Девопса" и погнали бороздить унылое болото российской ойтишной полянки? Превратим его в прекрасное сияющее море!

Ну и накидайте нам бустов чтоли, будем еще сторисами заебывать😁
https://news.1rj.ru/str/happy_devops?boost

Йо-хо-хо и кофе с печеньками!

Прямо утро девопса. Я уже вижу, как на входе стоит Head Of и встречает каждого из нас перед работой.

Общаться на одном языке

Вы же все видели эти прокисшие потуги на общение, которые выдают абсолютное большинство людей, что называется, "не из тусовки", но очень хотящие в нее попасть, пытаются общаться

Йоу-йоу, сноубординг, дискета!

Тексты вакансий пишут мудаки точно. Инфоканалы, которые ведут деврелы — полное и унылое говно. Зайдите на любую площадку с айтишным контентом и вы по щелчку пальцев найдете статьи, которые писали технари и которые были выложены только потому, что Компания заплатила владельцу площадки за это говно. И такого все больше и больше.

Не надо пытаться говорить на одном языке, будьте собой! А то складывается ощущение, что кто-то кого-то точно держит за дебила. Какой на этом можно построить HR-бренд, я не знаю🤷‍♂️

Проблема инструкций в интернете — проблема инструкций в ИТ. Феномен удивительный. 6 утра. Мне на старости лет в ИТ захотелось поставить openvpn сервер. Я человек вроде не глупый, иду в интернет. Казалось бы, входные условия простые. Есть центось, есть интернет.

Первые шаги "Как поставить сам OpenVpn" проходятся быстро. Но самое интересное начинается на инструкции EasyTls. Как человек простой, я вижу требования "Easy-RSA v3.0.6, OpenVpn 2.5.0" . Запускаю команду.
Так блет.
Error: Unsupported OpenSSL version: 1.0

Откуда взялось требование OpenSSL?
Ладно. Мы люди простые. Чем еще можно заняться в 6 утра. Соберем ка мы OpenSSL из исходников. Да последней версии. Спустя пару сигарет, радостного глядения в магию make — успех. Уверенность растет с каждой секундой.

Запуск EasyTls
Error: Unsupported OpenSSL version: 3.2
“Да *** конем оно, чтоб этому индусу составителю инструкции оторвало все детородные органы,шоб ему винда милениум снилась по ночам”
В принципе, путешествуя по компаниям, я чаще так же реагировал на документацию в компании. И на каракули девопсов, которым не давали ни время, не техписов. Не учили в принципе, как надо писать.

Пишите инструкции. Многие компании не осознают, что одно из главных требований к инженеру, не умение писать скрипты. А умение описать документацию. Да, мы понимаем, что на деле в процессе, когда инженер собирает такие же грабли, он теряет контекст и забывает половину действий.
Или наивно запускает плейбук, забывая все на свете.

Цена — 1 час такой работы инженера, это x30 затрат потом, когда приходят другие люди. В условиях, когда зависимости, пакеты, версии меняются каждый день — это может быть не супер спасением. Но базовые вещи сохраняются всегда. В любом процессе. Даже походу Unsupported OpenSSL version:3.2

https://infostart.ru/upload/iblock/a06/a06ba302ba5d5cbded6b72bd5771f9b7.png

Тема с документацией всегда вызывает дискуссию. Окей, вбросил.
Логично, раз сказал А, то и надо говорить Б. Иначе я буду тем же индусом, которому явно что-то надо оторвать.

Я задался вопросом лет 5 назад, как описать автоматизацию. Думая над стандартными блок схемами, я решил обратиться в бизнес анализ и их аннотации. И в принципе я нашел. IDEF0 позволяет просто описать процесс автоматизации. Поэкспериментируйте. Будет интересно.

В итоге, за годы в тимлидстве я свел документацию по девопсу до трех основных типов документов.
Первый тип - описание автоматизации. IDEF0 - велком. Просто, можно декомпозировать до многих документов, легко и гибко. Картинка пример.

Второй тип - архитектурная схема автоматизации, и архитектурная схема инфраструктуры. Благодаря экспериментам известно, что удобная схема представляет себя группировки серверов и сетей поверх этих групп. Связи помогают на схеме понять всем (включая ИБшников), куда смотреть.Рисует тимлид.

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

Но, это все “Советы Сары Львовны”. Однако, сказки про изменчивость мира девопса - это сказки) Если девопс закладывает в автоматизацию сам факт того, что она через год изменится - значит это хреновый девопс :)

https://habr.com/ru/companies/oleg-bunin/articles/786930/

Possible pilot deviation

Есть такой термин в авиации, отклонения пилота. Когда перечитываешь очередной материал про ИБ, DevOps, и концепции работы с безопасностью, задаешься вопросом, куда эти пилоты ведут наш самолет.


Я выработал две модели, в рамках которой весь мир делится либо на красное, либо на черное.

Первая модель - addictive (вызывающая привыкание) - которой следует большинство. Особенности модели - напихать анализаторов везде, где возможно, исходя из них уже чего-то делать, бегать махать руками на каждую CVE, и делать тонны QG для того, чтобы нагрузить код, систему. И безопасный пайплайн якобы.

Вторая модель - predictive (прогнозирующая) - выбор тру пацанов.
Особенности модели - мы разделяем системы и смотрим больше на их функциональность. Бекенд и фронтенд, и инстрафструктура, это разные доменные области, в рамках которых мы можем сначала разработать некоторую модель и архитектуру прогнозирующую риски. Например, бекенду плевать на CVE в рамках кубика. Ну объективно. Проблематику CVЕ можно обойти сегментацией сетей в облаке, правилами и контроля трафика + анализатор стоящий на отслеживание операций на хост машине. И обновляться раз в квартал. Экономия? значительная. Код микросервисов можно даже не гонять через анализаторы. Внезапно, так как есть другие способы его защищать.

“А как же пароли, ко-ко-ко, логины”. Для этого внезапно, можно научится наконец использовать профили и appconfig в коде. Убирать абстракции секретов из кубика, и работать только с конфигурационными файлами (которые кстати и были придуманы для этого). И конфигмапы совершенно случайно окажутся не нужны. Как и тонна доп лукошек, в которые складывают секреты, которым нужно строить еще защиту, для которой нужно еще создавать защищенные каналы.

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

Не страдайте possible pilot deviation.
Safety first - означает, что сначала лучше подумать, нежели потом бегать с коммунальными платформами, которые сами по себе создают угрозу компании, и несут тотальные затраты, чтобы их защищать. Я могу расписать еще более подробнее, если есть интерес. Для этого плюсик под пост.

Addictive model.

Заезженная модель. Почему я ее называю такой, так это по причине самого термина DevSecOps.
Как только ты начинаешь говорить про это, сразу появляются тонны ребят, которые как с кубиком, зальют тебе про анализаторы, оваспы, зависимости. Прям сходу. И приведут тонны выдуманной статистики, которую никто никогда не проверял, но она есть, потому что «Мы умные ребята, мы знаем, а вы тупые»

По сабжу. В чем особенности. Если мы взглянем в любимый нами интернет, и погуглим, чаще всего мы наткнемся на все известные картинки по процессу DevSecOps. При этом процесс в итоге на самом деле куцый, так как упор в этих картинках делается на встраивание в процесс автоматизации безопасности.

«Ага, мы защищаем якобы код, а сама инфраструктура – в задницу ее»
Если взглянуть не первый пункт – он называется всегда Planning. И там чаще всего все, что связано с кодом. Как-то так удобно выходит, что в истерике про взломы, DevSecOps зачем-то лезет в код, но не в инфраструктуру. В рамках пункта, методика упирается только в процесс автоматизации. И она не прогнозирует проблему. В рамках нее, мы работаем на самом деле только с 1-2 слоями.
1 слой код, второй слой приложение в контейнере и тд. И в эти два слоя напихивают тонну бесполезных вещей, забывая следующее: «Все что создается в ИТ – является слоеным пирогом. А это значит, что рассматривать надо весь продукт, исходя из теории Swiss Cheese model». Которую придумали умные люди до маркетологов из ИТ.

Данная методика приводит к тому, что мы пытаемся закрыть все дырки разом. Вместо того, чтобы понимать и планировать ДО, мы натравливаем кучу бесполезных вещей. Представим, что есть секрет. Благодаря методике, у нас есть анализаторы, которые проверяют наличие в коде. Вынуждая сложить секрет в хранилище, оттуда он перекочует в облако в конфиг мап в паасе, или хранилище паасовское. И? Секрет утечет оттуда, что делать? Очень внезапно, методика не объясняет, что делать. Она бесполезна, потому что, подход из принципа «Ну вы наставьте, СТАНИТИ БИЗОПАСНЕЕ». А что делать, если все же произошла утечка? На сколько быстро и оперативно мы развернем новое окружение? Поменяем секреты? Security Disaster Планы есть? Смена каналов связи? В этом то и есть ключ. В ситуации, не когда мы защитились "якобы", а когда мы представляем, что делать с нашей автоматизации, если все же утечка произошла. А это уже прогнозируемая модель.

Когда вы видите, что очередной ИБ офисир говорит «мы сделали девсекопс» - ждите, что именно его контора потом обосрется.

Завтра расскажу про predictive. И про швейцарский сыр. И как его применять.

https://habrastorage.org/webt/ez/vm/w2/ezvmw2ev2pm3rrflvwgwh_im3hg.png

Predictive model.

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

Представим ситуацию. Все же любят root в докер файле. Так же, как и считается, что из-за пары кривых контейнеров теперь все должны обязательно убирать рут.

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

Отсюда закономерный вопрос. Допустим есть бекенд в облаке. Как вы думаете, в каком месте находится слой сыра под названием root в докер файле?

На последнем. Внезапно. Потому что в проектировании, я понял, что нужно отталкиваться в первую очередь от первых кусочков. А там - физическая инфраструктура, сети, облачная инфраструктура, ролевая в облачной, ролевая в подписке, виртуальная сеть в подписке, ролевая над сетью, папки с ресурсами, ролевая в папках, бастион хосты, выделенные сети под бастионы, правила для сетей, пользователи внутри бастионов, впны в бастионы, SIEM и AV в бастионах, затем сами хосты с бд, кубиками, SIEM и AV в них, затем сами кубики с RBAAC, сетями внутри, правилами над ними сетевыми в VPC, затем секреты, которые касаются самого кубика, хранение секретов, затеееееем….конфигмапы, инит контейнеры, и только в конце всего это балагана - root в докерфайле. Как думаете. Буду ли я тратить время на рут в докерфайле?)
Нет. Швейцарский сыр позволяет поделить всю вашу инфраструктуру, как раз на слои. И заняться сначала базовыми вещами. Базовые вещи в любом облаке - это бастион, и человек со своей учеткой и правилами безопасности над ними. Оборонять сначала нужно самые уязвимые точки. А это чюловек. То есть вы. https://de.wikipedia.org/wiki/Schweizer-K%C3%A4se-Modell#/media/Datei:Swiss_cheese_model_of_accident_causation.png

В теории, теория и практика одинаковы. А на практике между теорией и практикой стоит русский управленец

(С) МистерС

Вчера состоялся минималистичный съезд клуба анонимных инженеров Happy Devops. Кроме цитаты, у меня появилась идея сделать один небольшой опрос. Будьте ИТшниками, поучаствуйте) Опрос анонимный, но нам будет интересно посмотреть мнение об усталости) Да и тем более, чем еще заняться в выходные. https://forms.gle/noQiBd9rgALJqgnv5

https://mightymediapress.com/sites/default/files/images/covers/vote.jpg

Допустим.

Мы тут покумекали, и Мистер С предложил идею. А что если, дать возможность выступить тем, кто этого хочет. И мы решили сделать еще один эксперимент. Наша задумка проста. Мы хотим сообщество людей, а значит, что эта площадка предназначается в первую очередь не для нас одних (себя любимых), но и для всех, кто хочет с нами это сообщество создавать.

И мы решили сделать вот что. Хотите написать свой пост? Сюда. Со своей подписью?) Велком.
Условия просты, как развернуть кубик. Отправляете свой пост в бота @HDFeedBackBot. Без мата. Либо заваулировать. Быть готовым к критике. И пред модерации. Мы хотим сообщество основанное на возможности говорить, быть услышанным. Которое построенно на критике и открытой полемике. Можно отправлять анонимно, в данном случае мы выложим от себя с подписью Аноним.

Бросить вызов сообществу? Welcome, мы не против. Бросить вызов нам? Мы только за. Задать сложный филосовский вопрос и представить свое видение - что такое Жевопс. Ну….Барух вам судья, будьте готовы к вентиляторным встряскам

Тексты публикуются "AS IS" и могут не совпадать с мнением редакции. Мы ничего не исправляем, ни единой запятой.

Хотите оставить подпись? Оставим. Даже можем ссылку на канал поставить, не жалко. Но текст должен быть хорошим и настоящим, это главное условие. Все решения команда модераторов принимает исходя из своего полного отсутствия вкуса и извращенных представлений о прекрасном

А вот и первая ласточка) Добрый человек, пожелавший остаться анонимным, прислал нам крик души.
Тексты публикуются "AS IS" и могут не совпадать с мнением редакции. Мы ничего не исправляем, ни единой запятой.

Хотите оставить подпись? Оставим. Даже можем ссылку на канал поставить, не жалко. Но текст должен быть хорошим и настоящим, это главное условие. Все решения команда модераторов принимает исходя из своего полного отсутствия вкуса и извращенных представлений о прекрасном

Скажи "Клей!"...

В it-сообществе последнее время модно рассуждать о "феномене devops", "роли devops", " что есть devops - культура или инструмент" и так далее.

Ответ на этот вопрос неожиданный и простой. DevOps - это свидетельство.
Свидетельство управленческой некомпетентности и торжества двойных стандартов.

Давным-давно, ещё при царе Дмитрии I, угораздило одного девопса возглавить отдел, который образовался после слияния отдела связи (там где STM, g.703, АТС, shdsl и прочие зоны Френеля) и отдела телекоммуникаций - компьютеры, принтеры, поддержка пользователей.
И вот прилетает как-то заявка с жалобой на неработающий факс.
"Связист" идёт в кабинет пользователя и наблюдает там сетевой фильтр без свободных мест и отключений от сети электропитания факс.
Не долго думая, выключает первую попавшуюся вилку и включает на ее место факс. Аппарат довольно урчит, "связист" спешно покидает место преступления.
Уже в дверях его настигает крик пользователя -"У меня монитор потух!"
"Мониторами я не занимаюсь. Звоните в телеком."

Это была лирическая зарисовка из жизни.
В тот момент не было ещё написано "жёлтых книжек", никто не знал о "стенах непонимания" и о конфликте development и operations. А проблема была. И решение ее было в зоне ответственности руководителя.

Сейчас мы наблюдаем нежелание менеджмента заниматься своими прямыми обязанностями. Это нежелание настолько сильное, что проще спрятать голову в песок, нанять отдельного человека, который будет нести ответственность за коммуникацию между коллегами.
Очевидно, что механик и водитель имеют кардинально противоположные задачи. Для улучшения взаимодействия нам срочно нужен garage-devops.
И вот тут мы подходим ко второй части проблемы. Человек - социальное существо, потребность общения с себе подобными заложена глубоко в недрах нашей "прошивки". Адекватность поведения - залог выживания в стае, племени, обществе.
И вот возникает движение хикикомори, которые асоциальны по природе.
В любой здоровой другой среде неумение эффективно взаимодействовать с коллегами не приветствуется. Однако, в IT вместо осуждения это встречает потакание.
Результат - на лицо, сущности умножаются, miscommunication выносится на запредельный уровень и начинает мешать бизнесу.
И бизнес, испугавшись "высоких технологий", готов платить немалые деньги, тому, кто готов решить вопрос.
Спрос рождает предложение - и мы видим легионы недопрограмистов-недоадминов-недоменеджеров, которые выступают в роли социального "клея".
Пресловутое "выгорание" - расплата за то, что devops вынужден пропускать через себя психологические вывихи с трёх сторон.

Вот и всё. Выводов не будет. Живите с этим. Желательно - дружно.

Аноним Петрович

Мнение редакции.

“Дорогой читатель, мы получили твое письмо и спешим тебя обрадовать. Ты прав. Почти. Но есть одно маленькое но. Если так подумать и посмотреть пошире, то IT просто в чем-то уникально. Если в истории промышленные революции происходили благодаря технологиям и прорыву, то в принципе devops - промышленная революция благодаря слабеньким манагерам. По факту то, автоматизация производства в ИТ и так должна была прийти.
Просто в ИТшечке это происходит благодаря 3 столпам. Премия, KPI и низкая квалификация начальства.
Последствия верны, у нас есть есть тонны полу-инженеров, полу-безопасников, полу-разработчиков, но которые сгорают не столько из-за начальства. А сколько из-за того, что будучи молодым направлением, сначала все строили бездари, а только потом мы начали понимать, что сначала нужна архитектура, архитектура автоматизации, что это надо считать, понимать, как делать красиво, эстетично, гибко, а не наслаивать тонны опенсорса и орать сколько контейнеров у кого длиннее. Но так как многое уже построено, а согласия в нашей среде нет - на нет и суда нет. Редакция приветствует твой пост, дорогой читатель, Лит. Сотрудник Мистер С.” Москва, журнал Happy Devops, 2024 год

Моё вчерашнее выступление на концерте и происходящий в это время аврал в ИТ навеяли. Реакция всех лидов вчера была такая, когда днс ожил наконец.