Happy Devops — сообщество адекватных инженеров

https://mightymediapress.com/sites/default/files/images/covers/vote.jpg Допустим. Мы тут покумекали, и Мистер С предложил идею. А что если, дать возможность выступить тем, кто этого хочет. И мы решили сделать еще один эксперимент. Наша задумка проста. Мы хотим сообщество людей, а значит, что эта площадка предназначается в первую очередь не для нас одних (себя любимых), но и для всех, кто хочет с нами это сообщество создавать. И мы решили сделать вот что. Хотите написать свой пост? Сюда. Со своей подписью?) Велком. Условия просты, как развернуть кубик. Отправляете свой пост в бота @HDFeedBackBot. Без мата. Либо заваулировать. Быть готовым к критике. И пред модерации. Мы хотим сообщество основанное на возможности говорить, быть услышанным. Которое построенно на критике и открытой полемике. Можно отправлять анонимно, в данном случае мы выложим от себя с подписью Аноним. Бросить вызов сообществу? Welcome, мы не против. Бросить вызов нам? Мы только за. Задать сложный филосовский вопрос и представить свое видение - что такое Жевопс. Ну….Барух вам судья, будьте готовы к вентиляторным встряскам

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

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

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

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

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 - означает, что сначала лучше подумать, нежели потом бегать с коммунальными платформами, которые сами по себе создают угрозу компании, и несут тотальные затраты, чтобы их защищать. Я могу расписать еще более подробнее, если есть интерес. Для этого плюсик под пост.

https://infostart.ru/upload/iblock/a06/a06ba302ba5d5cbded6b72bd5771f9b7.png Тема с документацией всегда вызывает дискуссию. Окей, вбросил. Логично, раз сказал А, то и надо говорить Б. Иначе я буду тем же индусом, которому явно что-то надо оторвать. Я задался вопросом лет 5 назад, как описать автоматизацию. Думая над стандартными блок схемами, я решил обратиться в бизнес анализ и их аннотации. И в принципе я нашел. IDEF0 позволяет просто описать процесс автоматизации. Поэкспериментируйте. Будет интересно. В итоге, за годы в тимлидстве я свел документацию по девопсу до трех основных типов документов. Первый тип - описание автоматизации. IDEF0 - велком. Просто, можно декомпозировать до многих документов, легко и гибко. Картинка пример. Второй тип - архитектурная схема автоматизации, и архитектурная схема инфраструктуры. Благодаря экспериментам известно, что удобная схема представляет себя группировки серверов и сетей поверх этих групп. Связи помогают на схеме понять всем (включая ИБшников), куда смотреть.Рисует тимлид. Третий тип - сложный, но его наличие - это договор. Паспорт системы. Куда включается архитектура, drp, ссылки на основные инструменты автоматизации, ответственные, бизнес владельцы, и вся реальная информация. Это не просто документ, это договор, по которому как раз выстраивается взаимодействие многих с многими. Но, это все “Советы Сары Львовны”. Однако, сказки про изменчивость мира девопса - это сказки) Если девопс закладывает в автоматизацию сам факт того, что она через год изменится - значит это хреновый девопс :)

Проблема инструкций в интернете — проблема инструкций в ИТ. Феномен удивительный. 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

Ну, надо сказать, тематика и температура текстов в канале значительно поменялись) С того времени, как мы с МистеромС начали эту вакханалию, отписалось больше сотни человек😳 Слабаки! 🤖 Все правильно, пусть валят читать одинаковые стопицот каналов про кубернетесы. Вот вас лично не заебали технические каналы про одно и тоже? Все пишут одно и тоже! Загнать в чатгпт англоязычный текст, чтобы она выдала саммари на русском и картиночку сгенерила. Пост готов, рекламки купили, теперь будем свою продавать! И каких инженеров мы хотим получить в таком инфополе? Технари плачут, ой какие сложные собесы. Ой, зачем вы это спрашиваете, если я буду все равно джейсоны перекладывать? Гайз, ничего не спрашивают у таджиков в озоне: из ведра не пьешь и слава богу, иди работай. А за хорошие бабки, надо поработать конечно. И не только на работе. Вот такой вот закон рынка: все требует инвестиций и никогда не известно заранее, окупятся они или нет Ты думал, что в жизни есть правила. А их нет🤷‍♂️ Есть такой чудо-ресурс, "ебаное-айти.ру", ссылку пока прикладывать не буду, я много еще напишу про их скулеж. Так вот там основная боль, она про "знал бы прикуп, жил бы в Сочи". Типа, как угадать технологию, которую надо учить, чтобы она была востребована? Ну типа там вот зашел в джаву 5 лет назад и заебца, работа есть. А коль пошел в ембеддед например, то все🤷‍♂️ Работы нет Вот потому и надо учить базу, блин. Вот потому и надо знать и понимать всю эту дрочь, потому что всё, вообще абсолтно всё, складывается из нее. А работодатели нанимают не перекладывателя джейсонов, а решателя проблем. Получается, к сожалению, редко. Бизнес — штука непредсказуемая, а жалобы на сложные собесы — это разговоры в пользу бедных. Да, капитализм жесток: чтобы поесть, придется поебашить

Общаться на одном языке Вы же все видели эти прокисшие потуги на общение, которые выдают абсолютное большинство людей, что называется, "не из тусовки", но очень хотящие в нее попасть, пытаются общаться Йоу-йоу, сноубординг, дискета! Тексты вакансий пишут мудаки точно. Инфоканалы, которые ведут деврелы — полное и унылое говно. Зайдите на любую площадку с айтишным контентом и вы по щелчку пальцев найдете статьи, которые писали технари и которые были выложены только потому, что Компания заплатила владельцу площадки за это говно. И такого все больше и больше. Не надо пытаться говорить на одном языке, будьте собой! А то складывается ощущение, что кто-то кого-то точно держит за дебила. Какой на этом можно построить HR-бренд, я не знаю🤷‍♂️

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

Ну что, ребятушки? Праздники прошли, нас поймали будни Как вы могли заметить, конечно же, нас стало двое) Я, всегда ваш покорный слуга, и некий МистерС, который лупит глаголом по сердцам людей, не разбирая своих и чужих Все так и останется, собственно. Простой маленький канал про счастливых девопсов мы хотим превратить в Большое Пиратское Медиа и "Счастливый девопс" будет как Счастливый Роджер на всем известном флаге 🏴‍☠️ Почему, блять, пиратское? Мы пытаемся сломать восторженный тон как по отношению к профессии, так и к сложившейся культуре "хуяк-хуяк и в продакшен", которая прикрыта кучей ярких тряпок со словами девопс-манифеста на них Вот потому и пиратское! Так, а что по контенту? Контента будет больше. Настроим контент-план и будем постить по расписанию. МистерС продолжит ебашить хомяков с хабра и прочих помоечек, ну а я просто буду делиться с вами своими мыслями, идеями и всем вот этим, что мы так любим. Мы хотим наступать по всем фронтам. Текст, видео, мемасики, тиктоки простигосподи, рилсы и прочая вся вот эта зумерская поебня. Никуда от нее не денешься конечно, мне может и привычнее было бы срать на форуме, но форумы читают три с половиной калеки, а мы хотим существенно колыхнуть медиапространство. Так что учимся новым форматам и работаем для вас, друзья! Ну что, поднимаем флаг "Счастливого Девопса" и погнали бороздить унылое болото российской ойтишной полянки? Превратим его в прекрасное сияющее море! Ну и накидайте нам бустов чтоли, будем еще сторисами заебывать😁 https://t.me/happy_devops?boost Йо-хо-хо и кофе с печеньками!

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

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

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

Растем год от года) В следующем будет что-то особенное, раз нас уже двое😊

https://3dnews.ru/1097669/microsoft-namerena-ubrat-lyudey-s-puti-stroitelstva-malih-yadernih-reaktorov-eto-budet-reshat-iskusstvenniy-intellekt Не так часто удаётся почитать действительно полезное применение ИИ (якобы ИИ). Но увидев сию прекрасную новость, я не могу не порадоваться. Ведь наступит день, когда тонны согласовываний с ИБ можно будет отдавать ИИ, и тогда я выдохну и перестану наконец заниматься бумажечной безопасностью. Когда-нибудь девопсов ждёт рай...

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

https://habr.com/ru/companies/swordfish_security/articles/778568/ Тянули сову на глобус, тянули…да получился DevSratOps. Пока наш прекрасный амбассадор амбассадорил, а я судорожно пытался понять, кто неадекватнее (я или мой мониторинг), попалась на глаза сей прекрасная статья. В общем почитав и вспомнив старые добрые времена, когда express 43 натягивало картинки со словом девопс на постулаты agile, я решил что эта песня будет длиться вечно. Так вот. Более всего мне понравилась эта цитата: “ Коэффициент пройденных контрольных точек (Passed Security Gates Ratio) также фокусируется на качестве кода, но на другом аспекте качества — информационной безопасности. Эта метрика непосредственно влияет на частоту сбоев.” Чигооооо бл…. Это как? Как оно влияет? Каким местом? В какой вселенной? С каких пор это начало влиять на частоту сбоев? Лупа отвечал за ИБ, а Пупа отвечал за код, и поэтому коэффициент CFR спиннера был самым низким. Вообще история с CFR сродни вестерну, в главных ролях которого телепузики пытаются на какой-то цифре угадать мелодию, когда им пора уже обратиться к урологу. Первое. CFR - чушь. CFR невозможно подсчитать объективно, потому что не каждый сбой равен деплою, не каждый сбой есть сбой, соотношение метрики должно соответствовать тоннам автотестов, а это господа, идите и посчитайте хоть кто-нибудь реальное покрытие и расскажите мне, как вы это сделаете. Во вторых. Когда мы хотим что-то мерять, вопрос для чего?) Окей, у нас дескать частые сбои. Часто ли мы сейчас видим это? Объективно нет. Кубик нивелирует, SRE что-то да найдут. Да и даже если мы видим проблему - ее чаще подадут, как “нужно пару мульярдов”. И кому-то КПИ. Но это точно не успешная история успеха. И махать DORA нынче - ну как бы нинада так.

Я сегодня работаю на форуме "Россия" в павильоне ВК. Я теперь амбассадор, вот какое слово модное на меня прилепили В целом, все очень круто и форум сделан прям крайне качественно. На выходные рекомендую запланировать один день на ВДНХ и погулять по павильонам. В нашем много всяких механик интерактивных, можно купить прикольного мерча от ВК Павильон прямо за фонтаном "Дружба народов", если пойдете сегодня, то меня можно узнать по белому худи VK Team, я тут один такой😁