How to become an author
Search
Write a publication
Pull to refresh

Comments 13

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

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


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


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


Total votes 2: ↑2 and ↓0+2
UFO just landed and posted this here
UFO just landed and posted this here

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

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

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

This comment wasn’t rated yet0
UFO just landed and posted this here
Дима, ты читал The Phoenix Project и DevOps Handbook? Там немного описывается, как подружить эти вещи. Вкратце — автоматизация трекинга изменений. В идеале — отсутствие апрувов. Да, может повышаться риск, но это компенсируется легкостью процесса деплоя, а значит, легкостью накатывания фиксов. Список изменений используется просто как история, чтобы понять, что кто и что сломал. Правда, там не про регулированный энтерпрайз.
P.S. The Phoenix Project — художка, стоит почитать хотя бы ради лулзов. Смех будет перемежаться со слезами.
This comment wasn’t rated yet0
Не читал. Опиши идею — нет колючей проволоки, но расстрел пост фактум?
This comment wasn’t rated yet0
Колючая проволока в несколько рядов (автоматизированные тесты и вот это все) есть между внесением изменения в репозиторий (коммит) и точкой «у нас есть пакет, мы готовы деплоить». Ее цель — доказать, что изменение не может быть задеплоено. Если она не смогла этого сделать, то все, изменение может выказываться без дополнительных аппрувов и прочей бюрократической «колючей проволоки». Но все деплои, конечно, трекаются, чтобы в случае проблем можно было найти следы.
This comment wasn’t rated yet0

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


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

This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr