NDA 😞

ITSM как идея не противоречит идеям devops

хорошо что есть нда и можно не рассказывать "ужасы нашего городка"

Подайте мне девопсов из сбера! У меня есть, что им рассказать на повышенных тонах. И кого-нибудь из антифрода

а че там? могу твое сообщение зафорвардить)

Я выпил коньяку, успокоился и понял, что к девопсу там претензий нет. Только к антифроду, который 5 раз к ряду блокирует операцию закрытия закончившегося вклада. То есть блокировка с разавторизацией приложения и локом онлайн-банкинга -> звонок на подтверждение операции -> подтверждение что я реально хочу закрыть вклад (не вывести миллионы в оффшор за пределы банка, а просто закрыть) -> разблокировка клиент-банка -> попытка закоыть вклад -> go to first step

Ну тут как посмотреть. Девопс fail safe, fail fast.  А в ITSM fail под запретом 😉

Итсм вообще и итил в частности нигде не говорит, что фейл под запретом

Основная идея итсм - фокус на потребностях клиентов (внутренних и внешних), которым мы предлагаем сервисы.

Абсолютно верно, а главное качество сервиса - соответствие принятому SLA. Следовательно любые сбои, приводящие к его нарушению - зло. А что может привести к сбою уже исправно работающий сервис? Правильно - его изменение. Отсюда естественное развитие итсм процесса в сторону снижения количества изменений и дополнительных quality gates. А в бюрократических реалиях ещё и размытие ответственности => дополнительные, порой бессмысленные согласования CHG.

В итоге упираемся не в технические ограничения, а в организационные. Хочется узнать опыт именно в этой части. Пока вижу два примера (Сбер и Райф), когда безжалостно ломают орг-структуру, но это реально 'боль', и тут пока верхи по настоящему не захотят - низы не смогут.
Может есть какой секрет успеха с менее радикальными решениями?

Вы можете договориться на SLA - минимум 20 новых фич в неделю, доступность 50% времени 😉 Я понимаю, что не решаю вашей проблемы, я лишь хочу нашим маленьким слушателям внести поправку, что итсм и итил - это не всегда бюрократические махины. Каждый сам решает, что именно взять из этого сборника лучших практик. Там хорошие процессы работы с инцидентами, с капасити, с проблемами, например.

Согласен с Вами, что каждый сам решает и, что в целом итсм полезная штука, которая пытается минимизировать хаос. Менять SLA - не очень хорошо.))))

По технике можно вопрос? С Ansible есть какие-то подводные камни в части автоматизации развертывания сложных интеграционных сред? Может быть есть более подходящие инструменты?

Само по себе предложение очень сложное)

«автоматизации развертывания сложных интеграционных сред» это космолет. не понятно что за этим скрывается

Кубер вот им развертывают..:)

На завтра забронирован стол в Friends forever на 9:00. На 10 человек, на Валерию.
ул. Малая Никитская, дом 2/1 стр.1

Диски им меняют еще))) https://habr.com/ru/company/odnoklassniki/blog/452110/

Да вроде все инструменты могут примерно одно и тоже. Плюс Ansible легкое вхождение и без агентов. Итоги обсуждения в devops_ru