Песнь льда (кровавый Enterprise) и пламени (DevOps и IaC)

[SicYar]

Соболезную) похожие условия последнее время (последние 4 года в 2 разных компаниях) наблюдаю и к счастью удавлось немного это сдвинуть с мертвой точки. Самое наверное сложное — сдвинуть с мертвой точки восприятие Dev и Оps, которым ваш этот DevOps побоку. Тоесть стоит начать с решения именно проблем людей, который там работают, принести им чтото новое и показать полезность стратегии, тогда собственно нововведения, приятные вам будут проходить легче.

[rzerda]

Ммм, Remedy. Наблюдал два вида change management process и DevOps:

1. Не-ИТ компания на другом конце планеты. «Окей, мы вам сделаем этот доступ, уже сделали заявку, но CAB соберётся через какое-то время, надо подождать». Через четыре часа после первого письма доступ появляется.

   
   

2. Не самый маленький оператор всего на этом конце планеты. Вопль самопровозглашенного DevOps-а: «да выключите уже этот @#%! Puppet! Он задолбал перетирать то, что я руками в конфигурации на хостах пишу!»

   
   

[Tzimie]

О, как это знакомо!

[MaxAhmed]

Не знаю что имел ввиду автор под современными itsm системами, но банальный micro focus service manager ( бывший hpsm) имеет rest api через который можно любой документ заполнить. Ну если это включено конечно.
В остальных enterprise itsm системах думаю все примерно так же. Я к тому, что дело не в системах обычно, а в нежелании тех кто их поддерживает и администрирует сделать нормальное взаимодействие системы с окружением.

[BobArctor]

Большинство ритуалов релиз менеджмента на местах появились не просто так. Они следствие боли случившейся в прошлом. В легком варианте боль выражалась в переработках и emrgency break-fix, в тяжелых и особо тяжелых это лишений премий, увольнения, штрафы от регуляторов. Ни один PM(и выше) в здравом уме не примет все эти риски ради того чтобы линейному заменяемому разработчику стало «хорошо».
Если хочется что-то менять, то:
1. Разработку изменения начинать с вопроса: «Какую конкрентную боль/риск это изменение снижает или решает в масштабе существующего процесса?»
2. PoC должен показывать реальные измеримые изменения на -N ошибок развертывания/+N сохраненных денег или часов
3. Изменение не должно создавать новых проблем на организационном уровне.
4. Забыть о быстрых результатах. От успешного PoC до успешного внедрения в энтерпрайзе пройдет год и более.
5. Энтерпрайзу в целом существующее положение дел норм. Если нет, то трасформации начинаются далеко за пределами ответственности отдела разработки.

[Tzimie]

Это так, но как вы думаете, на каком рубеже остановится проникновение девопс в энтерпрайз?

[andreycha]

Дима, ты читал The Phoenix Project и DevOps Handbook? Там немного описывается, как подружить эти вещи. Вкратце — автоматизация трекинга изменений. В идеале — отсутствие апрувов. Да, может повышаться риск, но это компенсируется легкостью процесса деплоя, а значит, легкостью накатывания фиксов. Список изменений используется просто как история, чтобы понять, что кто и что сломал. Правда, там не про регулированный энтерпрайз.
P.S. The Phoenix Project — художка, стоит почитать хотя бы ради лулзов. Смех будет перемежаться со слезами.

[Tzimie]

Не читал. Опиши идею — нет колючей проволоки, но расстрел пост фактум?

[andreycha]

Колючая проволока в несколько рядов (автоматизированные тесты и вот это все) есть между внесением изменения в репозиторий (коммит) и точкой «у нас есть пакет, мы готовы деплоить». Ее цель — доказать, что изменение не может быть задеплоено. Если она не смогла этого сделать, то все, изменение может выказываться без дополнительных аппрувов и прочей бюрократической «колючей проволоки». Но все деплои, конечно, трекаются, чтобы в случае проблем можно было найти следы.

[AntiHelper]

Ну и какое может быть в принципе решение? У системы ITSM крайне примитивный API чтобы автоматически генерить документы. Да и вообще, большинство таких систем идет из времен мейнфреймов. Может кто знает действительно современные системы ITSM

Недавно читал про itop, на мой взгляд — это то, что Вам нужно. Сам ещё не пробовал(