Right Honorable Gentlemans….and Lady’s

Последние несколько дней гремит новость с увольнением Сэма Альтмана.
При этом его позиция в СМИ уже поменялась несколько раз. То он на полшишечки CEO, то уволен. Но интересен не факт его перепрыгивания и шума. Давайте обсудим обратную сторону. Все мы взрослые люди и пониманием, что “игры престолов” присутствуют во всех компаниях.

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

С другой стороны, иногда глупая провокация и есть способ саботажа, если есть что предложить потом тем, кто его устраивает. И не важно, исполнителей можно убрать, ведь если упадут акции или будет нанесен ущерб производству - почему бы и нет. Эффект будет достигнут. Определенно это интересная дилемма.

Приглашаются к обсуждению еще варианты. Ваш Мистер С.

https://habr.com/ru/companies/flant/articles/775646/

Аутсорс. Даешь аутсорс. Лохъ не мамонт, лохъ не вымрет.

С прекрасным аутсорсом я столкнулся в молодости. Когда работал в нем. И всегда не понимал убеждения, что это дешевле. Во первых нет. Еще дороже. Аутсорс ни за что не отвечает. Во вторых это чушь. Чтобы аутсорс жил, ему нужно зарабатывать.

А если ему нужно зарабатывать, то ему нужно не работу сделать, а усидеть подольше. И получить побольше.

Я столкнулся с такой аутсорс девопс командой из Епама в свое время. Скажем так, контора получала двойную сумму за 3ех человек, а работа этих людей стоила 7 месяцев переделок. Они проработали уже год, но цена их работы в итоге составила….0. Контора периодически меняла джунов, чтобы обучаться за счет заказчика. Однажды в субботу утром лид этой команды устроил скандал и рассказал, как заберет всю команду куда-то. Шуму было много. Вплоть до извинений манагеров ЕПАМА. Просто потому, что его не устраивала ситуация, что у заказчика появился лид. После этого я перестал верить в девопс команды на аутсорсе. Да, можно взять разработчика, тестировщика, аналитика. Но брать девопс аутсорс команду - такая себе идейка. Слишком дороги последствия этого. Ну или если у вас есть сильный лид, который понимает, когда она больше будет не нужна и ставит жесткие условия работы. Но аутсорс обычно в таких случаях убегает сам быстро. Не выгодно)
Открыто для обсуждений. Мистер С.

https://habr.com/ru/articles/776240/

Кто потирает ладошки? Я

Пора обсудить успехи одних ребят. Цитата дословно:

“Я считаю, что DevOps — это суперинженер, который и в поддержке понимает что-то, и в разработке, и самое главное: он чувствует ответственность на стыке Dev и Ops.”

А нет, расходимся. Успехов не будет. Годы идут, а у них все по старому.

Но может быть, все же, есть шансы?

Цитата еще одна:

“DevOps-инженер со временем, возможно, станет централизованной функцией и будет заниматься развитием мастер-системы, а не разработкой очередного конвейера.”

Нет, все таки расходимся.

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

https://habr.com/ru/companies/omk-it/articles/777180/


Если бы у бабушки было….Он был бы девопсом.


Так вот. Ловушка, которая называется “давайте все роботизируем, автоматизируем”, стандартная для молодых Девопсов. Когда они еще не умеют считать затраты, выгоду и кол-во прикладываемых сил, рождаются плейбуки для автоматизации всего. Которые потом успешно приходится переделывать.

Ловушкой этой больны все так или иначе. Забывая, что автоматизация может стоить дороже самой операции. Можно найти много видео, где китайский рабочий сидя на конвейере, делает глупую операцию по перекладыванию продукции. Но вот в чем смысл. Частенько поставить станок, обслуживать, поддерживать, гораздо дороже, чем один китайский “н*гра-заряжающий”.

Это касается и ИТ. На удивление, не все возможно и нужно автоматизировать или роботизировать. Проще иногда, посадить “якобы SRE” пялится в мониторинг и звонить куда надо в случае чего.

“Мы делаем цифровую трансформацию” - частенько на деле звучит “Мы попиливаем KPI”

Я сегодня работаю на форуме "Россия" в павильоне ВК. Я теперь амбассадор, вот какое слово модное на меня прилепили

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

Павильон прямо за фонтаном "Дружба народов", если пойдете сегодня, то меня можно узнать по белому худи VK Team, я тут один такой😁

https://habr.com/ru/companies/swordfish_security/articles/778568/

Тянули сову на глобус, тянули…да получился DevSratOps.

Пока наш прекрасный амбассадор амбассадорил, а я судорожно пытался понять, кто неадекватнее (я или мой мониторинг), попалась на глаза сей прекрасная статья.

В общем почитав и вспомнив старые добрые времена, когда express 43 натягивало картинки со словом девопс на постулаты agile, я решил что эта песня будет длиться вечно.

Так вот. Более всего мне понравилась эта цитата: “ Коэффициент пройденных контрольных точек (Passed Security Gates Ratio) также фокусируется на качестве кода, но на другом аспекте качества — информационной безопасности. Эта метрика непосредственно влияет на частоту сбоев.”

Чигооооо бл…. Это как? Как оно влияет? Каким местом? В какой вселенной? С каких пор это начало влиять на частоту сбоев? Лупа отвечал за ИБ, а Пупа отвечал за код, и поэтому коэффициент CFR спиннера был самым низким.

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

Первое. CFR - чушь. CFR невозможно подсчитать объективно, потому что не каждый сбой равен деплою, не каждый сбой есть сбой, соотношение метрики должно соответствовать тоннам автотестов, а это господа, идите и посчитайте хоть кто-нибудь реальное покрытие и расскажите мне, как вы это сделаете.

Во вторых. Когда мы хотим что-то мерять, вопрос для чего?) Окей, у нас дескать частые сбои. Часто ли мы сейчас видим это? Объективно нет. Кубик нивелирует, SRE что-то да найдут. Да и даже если мы видим проблему - ее чаще подадут, как “нужно пару мульярдов”. И кому-то КПИ. Но это точно не успешная история успеха. И махать DORA нынче - ну как бы нинада так.

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

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

Ну штош. Последний рабочий день в этом году. “Случайности не случайны”, как говорилось в одном мультике. Казалось бы. Каков был шанс, что два человека встретятся в одной кальянной, запишут целую серию, начнут генерировать идеи. Удивительно, но бывает и такое. И в конце нового года, когда наконец все девопсы подводят итоги уборки хлопковых плантаций для больших белых господ, я пожелаю вам больше случайностей)
Нам предстоит немало работы. Грамотная осознанная критика - противовес, которого всегда не хватает любому сообществу. Мы будем расширять наши пиратские девопс съезды, для тех, кто хочет услышать идеи, критику, и размышления. Продолжим снимать ламповые эпизоды. В общем, харрр харррр харррр.
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