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 год

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

Анализ 153 млн строк позволяет обвинить Copilot в снижении качества кода разработчиков / Хабр
https://habr.com/ru/news/789628/

“У вас тут новые премии нарисовались”


Было логично, что Copilot может гавнокодить. Но взять целый фулл-хауз на 153 млн строк…. Мммм, вкусняшка.

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

Потому что логично, что пока самолет не упадет, проблема не вылечится.

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

Как вы думаете, что дальше?)

Я тут (от нечего делать😁) почитал всякое интересное про историю мирового БигБизнеса) И вы знаете, там стооооолько всего интересного и стооооолько всяких любопытных фактов)

В общем, готов пройти мимо всех программных комитетов всех конференций и рассказать лично вам в оффлайне (а тем кто не сможет, то пототм в записи) и абсолютно безвозмездно прекраснейший и интереснейший доклад на тему "История крахов крупнейших компаний XX-XXI веков". Повспоминаем, посмотрим на графики, обсудим, зададим интересные вопросы.

Знаете, как говорят? Те, кто не знает историю, обречен на ее повторение.

О времени и месте проведения события сообщим дополнительно)

В чатике прошел чУдный субботний стрим, даже вон котики поучаствовали)

Очень много поговорили про развитие в профессии, про цели, про то как расти и куда расти. Запись есть в чатике, если интересно)

В целом, это был пробный шар, вроде заходит, будем работать над улучшениями)

ХэппиДевопс Клуб: https://news.1rj.ru/str/+NmZp0U69mEgxYWJi

Слушайте и не говорите потом, что не слышали) В субботу, в hack-пространстве Backspace в Питере состоится запись очередного нашего эпизода, а также прекрасный творческий вечер) расскажем интересного