ITIL

160 views
Skip to first unread message

Evgeny Tarasov

unread,
Jun 6, 2014, 11:53:18 AM6/6/14
to devo...@googlegroups.com
Привет Devopsru!

Скажите, а что вы думаете об ITIL ?

Делаете ли вы change management и каталогизацию configuration items ?
Страдаете ли от неразберихи, постоянных поломок и никто ничего не знает кроме одного человека?
Или может от забюрократизированности всех процессов работы?

Заранее спасибо за ваше мнение!

Timur Batyrshin

unread,
Jun 14, 2014, 3:44:34 PM6/14/14
to devo...@googlegroups.com
А какую задачу бизнеса вы пытаетесь решить при помощи ITIL, и какой размер организации?

Если я правильно понимаю, вы просто хотите повысить прозрачность организационных процессов в команде.

Это можно делать при помощи ITIL (формализация процессов), Agile (форсирование личного обмена опытом между
сотрудниками), Devops (создание общей технологической основы процессов), или любых других методов — наверняка еще какие-то есть.
Что применять — сильно зависит от размера, специфики работы организации, уровня (технического, культурного и т.д) сотрудников
и управления и многого другого.

Каждое из них — это не "свод законов", а набор каких-то практик, которые хорошо работают вместе, но часто могут
использоваться и по-отдельности, если они решат вашу какую-то конкретную задачу.


пятница, 6 июня 2014 г., 19:53:18 UTC+4 пользователь Evgeny Tarasov написал:

Evgeny Tarasov

unread,
Jun 14, 2014, 4:19:01 PM6/14/14
to devo...@googlegroups.com
Спасибо вам за ваш ответ!

Я использую ITIL как словарь терминов и обзорный справочный каталог практик.

Я бы хотел немного уточнить вопрос.

Парни, которые написали The Visible Ops Handbook утверждают что change management это обязательное и ключевое условие высокой производительности IT подразделений. Но в своём опыте я нигде не видел чтобы что-то похожее кто-либо применял. В связи этим у меня и возник этот вопрос, бывает ли такое в природе. Может быть просто мне не посчастливилось работать в компаниях, которые по мнению авторов книги можно назвать высокопроизводительными?

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

По поводу бюрократии - многие методологии предписывают кучу процессов и тому подобной менеджерской деятельности. Возможно ли существование высокопроизводительной организации IT Operations без оверхэда на процессы, бюрократию, чтобы всё было просто и гибко, чтобы все задачи можно было просто брать и делать, и чтобы процесс масштабировался на 5-10-50 человек, и у каждого было понимание системы, и чтобы ничего не ломалось часто, обеспечивалась хорошая безопасность, доступность, управляемость, масштабируемость, скорость внесения изменений по требованиям бизнеса, прозрачность, соответствие best practices, быстрое освоение и внедрение современных технологий, отказоустойчивость и избыточность, бэкапы и отработанные сценарии восстановления после аварий, быстрая скорость реакции на сбои, проактивное планирование capacity, и т.д. ?
Может ли кто-нибудь поделиться опытом работы в компании, где всё это поставлено на высоком уровне и нет хронических проблем?

суббота, 14 июня 2014 г., 23:44:34 UTC+4 пользователь Timur Batyrshin написал:

Anton Koldaev

unread,
Jun 14, 2014, 5:39:52 PM6/14/14
to devo...@googlegroups.com
Может ли кто-нибудь поделиться опытом работы в компании, где всё это поставлено на высоком уровне и нет хронических проблем?

То есть вы просите подробно описать все процессы в компании? Вряд ли кто-то это будет делать.


--
Вы получили это сообщение, поскольку подписаны на группу "devopsru".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес devopsru+u...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.



--
Best regards,
Koldaev Anton

Ivan Evtuhovich

unread,
Jun 15, 2014, 9:39:32 AM6/15/14
to devo...@googlegroups.com
Евгений, вам проще будет прийти на одну из тусовок и поговорить с коллегами в неформальной обстановке, чтобы они рассказали, как весь процесс устроен у них.

Текстом это передать — это целая книжка.


2014-06-15 0:19 GMT+04:00 Evgeny Tarasov <etaras...@gmail.com>:

--

Slawa Olhovchenkov

unread,
Jun 15, 2014, 2:09:25 PM6/15/14
to devo...@googlegroups.com
On Sat, Jun 14, 2014 at 01:19:01PM -0700, Evgeny Tarasov wrote:

> Спасибо вам за ваш ответ!
>
> Я использую ITIL как словарь терминов и обзорный справочный каталог практик.
>
> Я бы хотел немного уточнить вопрос.
>
> Парни, которые написали The Visible Ops Handbook утверждают что change
> management это обязательное и ключевое условие высокой производительности
> IT подразделений. Но в своём опыте я нигде не видел чтобы что-то похожее
> кто-либо применял. В связи этим у меня и возник этот вопрос, бывает ли
> такое в природе. Может быть просто мне не посчастливилось работать в
> компаниях, которые по мнению авторов книги можно назвать
> высокопроизводительными?
>
> Помимо этого мне приходилось видеть много случаев когда системное
> администрирование это очень нагруженная и связанная с сильным стрессом
> деятельность, в результате у которой всё равно низкий аптайм, постоянные
> мелкие и крупные проблемы и очень много драмы как на стороне сисадминов так
> и на стороне пользователей. Мне очень интересно было бы услышать про опыт
> других людей.

это значит плохие админы, программисты и жадное руководство.

> По поводу бюрократии - многие методологии предписывают кучу процессов и
> тому подобной менеджерской деятельности. Возможно ли существование
> высокопроизводительной организации IT Operations без оверхэда на процессы,
> бюрократию, чтобы всё было просто и гибко, чтобы все задачи можно было
> просто брать и делать, и чтобы процесс масштабировался на 5-10-50 человек,
> и у каждого было понимание системы, и чтобы ничего не ломалось
> часто,

50 человек и все понимают сложную систему?
ну я не знаю.
вот какой Internet IX. будет ли в какой стране 50 человек, и у каждого
-- понимание этой системы?
что-то я сомневаюсь.

Ivan Evtuhovich

unread,
Jun 15, 2014, 3:08:44 PM6/15/14
to devo...@googlegroups.com
Мои пять копеек.


2014-06-15 22:09 GMT+04:00 Slawa Olhovchenkov <s...@zxy.spb.ru>:
On Sat, Jun 14, 2014 at 01:19:01PM -0700, Evgeny Tarasov wrote:

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

это значит плохие админы, программисты и жадное руководство.

Я бы убрал слово "плохие". Тут ошибка, по моему мнению, исключительно руководства, что они не видят проблемы и нанимают людей, которые не соответствуют уровню решаемых задач, не вкладывают ресурсы в развитие команды и образование сотрудников.
 
> По поводу бюрократии - многие методологии предписывают кучу процессов и
> тому подобной менеджерской деятельности. Возможно ли существование
> высокопроизводительной организации IT Operations без оверхэда на процессы,
> бюрократию, чтобы всё было просто и гибко, чтобы все задачи можно было
> просто брать и делать, и чтобы процесс масштабировался на 5-10-50 человек,
> и у каждого было понимание системы, и чтобы ничего не ломалось
> часто,

50 человек и все понимают сложную систему?
ну я не знаю.
Здесь я согласен, так не может быть в принципе. Тут как раз задача стоит, как построить взаимодействие так, чтобы каждый из 50 знал, кого и о чем спрашивать, и имел не так много возможностей "все сломать", при этом чтобы у него осталось много возможностей что-то сделать, не натыкаясь каждый раз на отсутсвтие прав доступа и сложные бюррократические процедуры согласования/разрешения. И где лежит этот баланс и какой он — сильно зависит от многих факторов.
 

Slawa Olhovchenkov

unread,
Jun 15, 2014, 4:12:58 PM6/15/14
to devo...@googlegroups.com
On Sun, Jun 15, 2014 at 11:08:43PM +0400, Ivan Evtuhovich wrote:

> > > По поводу бюрократии - многие методологии предписывают кучу процессов и
> > > тому подобной менеджерской деятельности. Возможно ли существование
> > > высокопроизводительной организации IT Operations без оверхэда на
> > процессы,
> > > бюрократию, чтобы всё было просто и гибко, чтобы все задачи можно было
> > > просто брать и делать, и чтобы процесс масштабировался на 5-10-50
> > человек,
> > > и у каждого было понимание системы, и чтобы ничего не ломалось
> > > часто,
> >
> > 50 человек и все понимают сложную систему?
> > ну я не знаю.
> >
> Здесь я согласен, так не может быть в принципе. Тут как раз задача стоит,
> как построить взаимодействие так, чтобы каждый из 50 знал, кого и о чем
> спрашивать, и имел не так много возможностей "все сломать", при этом чтобы
> у него осталось много возможностей что-то сделать, не натыкаясь каждый раз
> на отсутсвтие прав доступа и сложные бюррократические процедуры
> согласования/разрешения. И где лежит этот баланс и какой он - сильно
> зависит от многих факторов.

если вы по проблеме сумели идентифицировать отвественного -- это
значит вы её уже решили. т.е. мы опять имеем 50 человек и все
понимают.

Evgeny Tarasov

unread,
Jun 15, 2014, 5:09:26 PM6/15/14
to devo...@googlegroups.com
Иван, в нашей провинции не так уж и много профильных тусовок :-)

С книжками проблем нет :-) Хотелось бы услышать какие из практик, описанных в книжках, реально работают (в России), приживаются, и приносят пользу.

Я о своём опыте обязательно напишу, как только появятся значимые результаты.

воскресенье, 15 июня 2014 г., 17:39:32 UTC+4 пользователь Ivan Evtuhovich написал:

Evgeny Tarasov

unread,
Jun 15, 2014, 5:13:49 PM6/15/14
to devo...@googlegroups.com


воскресенье, 15 июня 2014 г., 23:08:44 UTC+4 пользователь Ivan Evtuhovich написал:
Мои пять копеек.


2014-06-15 22:09 GMT+04:00 Slawa Olhovchenkov <s...@zxy.spb.ru>:
On Sat, Jun 14, 2014 at 01:19:01PM -0700, Evgeny Tarasov wrote:

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

это значит плохие админы, программисты и жадное руководство.

Я бы убрал слово "плохие". Тут ошибка, по моему мнению, исключительно руководства, что они не видят проблемы и нанимают людей, которые не соответствуют уровню решаемых задач, не вкладывают ресурсы в развитие команды и образование сотрудников.

А бывают ли вообще случаи в дикой природе, когда админы и программисты отличные, руководство грамотное и не жадное. Когда админы работают с полной самоотдачей и получают реальные осязаемые результаты и явный положительный фидбэк, руководители делают всё как надо, а пользователи счастливы ?
 
 
> По поводу бюрократии - многие методологии предписывают кучу процессов и
> тому подобной менеджерской деятельности. Возможно ли существование
> высокопроизводительной организации IT Operations без оверхэда на процессы,
> бюрократию, чтобы всё было просто и гибко, чтобы все задачи можно было
> просто брать и делать, и чтобы процесс масштабировался на 5-10-50 человек,
> и у каждого было понимание системы, и чтобы ничего не ломалось
> часто,

50 человек и все понимают сложную систему?
ну я не знаю.
Здесь я согласен, так не может быть в принципе. Тут как раз задача стоит, как построить взаимодействие так, чтобы каждый из 50 знал, кого и о чем спрашивать, и имел не так много возможностей "все сломать", при этом чтобы у него осталось много возможностей что-то сделать, не натыкаясь каждый раз на отсутсвтие прав доступа и сложные бюррократические процедуры согласования/разрешения. И где лежит этот баланс и какой он — сильно зависит от многих факторов.

Именно!
 
 

Evgeny Tarasov

unread,
Jun 15, 2014, 5:17:14 PM6/15/14
to devo...@googlegroups.com, s...@zxy.spb.ru


понедельник, 16 июня 2014 г., 0:12:58 UTC+4 пользователь Slawa Olhovchenkov написал:

Именно это я и имел в виду. Хотя цифра 50 взята с потолка. Я считаю что эффективное масштабирование хотя бы на несколько человек - это прорыв. Так, чтобы во всё разбирался только один человек и никто больше - такое приходилось видеть. Добавление людей при этом не эффективно, т.к. всё завязано на одного человека, нет никакой документации и стандартизации. А со стороны может выглядеть как будто этот один человек умнее всех, а остальные не очень квалифицированы.

Slawa Olhovchenkov

unread,
Jun 15, 2014, 5:26:48 PM6/15/14
to devo...@googlegroups.com
On Sun, Jun 15, 2014 at 02:13:49PM -0700, Evgeny Tarasov wrote:

>
>
> воскресенье, 15 июня 2014 г., 23:08:44 UTC+4 пользователь Ivan Evtuhovich
> написал:
> >
> > Мои пять копеек.
> >
> >
> > 2014-06-15 22:09 GMT+04:00 Slawa Olhovchenkov <s...@zxy.spb.ru
> > <javascript:>>:
> >
> >> On Sat, Jun 14, 2014 at 01:19:01PM -0700, Evgeny Tarasov wrote:
> >>
> >> > Помимо этого мне приходилось видеть много случаев когда системное
> >> > администрирование это очень нагруженная и связанная с сильным стрессом
> >> > деятельность, в результате у которой всё равно низкий аптайм, постоянные
> >> > мелкие и крупные проблемы и очень много драмы как на стороне сисадминов
> >> так
> >> > и на стороне пользователей. Мне очень интересно было бы услышать про
> >> опыт
> >> > других людей.
> >>
> >> это значит плохие админы, программисты и жадное руководство.
> >>
> >> Я бы убрал слово "плохие". Тут ошибка, по моему мнению, исключительно
> > руководства, что они не видят проблемы и нанимают людей, которые не
> > соответствуют уровню решаемых задач, не вкладывают ресурсы в развитие
> > команды и образование сотрудников.
> >
>
> А бывают ли вообще случаи в дикой природе, когда админы и программисты
> отличные, руководство грамотное и не жадное. Когда админы работают с полной
> самоотдачей и получают реальные осязаемые результаты и явный положительный
> фидбэк, руководители делают всё как надо, а пользователи счастливы ?

нет, разумеется.

Slawa Olhovchenkov

unread,
Jun 15, 2014, 5:30:25 PM6/15/14
to devo...@googlegroups.com
ну можем получить еще вариант -- никто не разбирается во всём.
документация -- устарела/не соответсвует действительности.
пользователь по процедуре гоняется по кругу.
ради копеешной проблемы собирается семь телефонных совещаний с
клиентом по два часа.
результат -- хуй.
зато ИБД в полный рост. и наверняка ITIL соответсвует и ISO9001 тоже.

Evgeny Tarasov

unread,
Jun 15, 2014, 8:52:50 PM6/15/14
to devo...@googlegroups.com, s...@zxy.spb.ru


понедельник, 16 июня 2014 г., 1:30:25 UTC+4 пользователь Slawa Olhovchenkov написал:

Звучит правдоподобно

Ivan Evtuhovich

unread,
Jun 16, 2014, 2:37:54 AM6/16/14
to devo...@googlegroups.com
Доброе утро.



Я бы убрал слово "плохие". Тут ошибка, по моему мнению, исключительно руководства, что они не видят проблемы и нанимают людей, которые не соответствуют уровню решаемых задач, не вкладывают ресурсы в развитие команды и образование сотрудников.

А бывают ли вообще случаи в дикой природе, когда админы и программисты отличные, руководство грамотное и не жадное. Когда админы работают с полной самоотдачей и получают реальные осязаемые результаты и явный положительный фидбэк, руководители делают всё как надо, а пользователи счастливы ?
 
Конечно нет, как и любая идеальная концепция, это направление, куда стоит стремиться. Для каждого конкретного бизнеса задача лишь сделать, чтобы IT работало эффективнее, чем "в среднем по рынку", чтобы получить конкурентное преимущество.
 
 
> По поводу бюрократии - многие методологии предписывают кучу процессов и
> тому подобной менеджерской деятельности. Возможно ли существование
> высокопроизводительной организации IT Operations без оверхэда на процессы,
> бюрократию, чтобы всё было просто и гибко, чтобы все задачи можно было
> просто брать и делать, и чтобы процесс масштабировался на 5-10-50 человек,
> и у каждого было понимание системы, и чтобы ничего не ломалось
> часто,

50 человек и все понимают сложную систему?
ну я не знаю.
Здесь я согласен, так не может быть в принципе. Тут как раз задача стоит, как построить взаимодействие так, чтобы каждый из 50 знал, кого и о чем спрашивать, и имел не так много возможностей "все сломать", при этом чтобы у него осталось много возможностей что-то сделать, не натыкаясь каждый раз на отсутсвтие прав доступа и сложные бюррократические процедуры согласования/разрешения. И где лежит этот баланс и какой он — сильно зависит от многих факторов.

Именно!
 
 

Ivan Evtuhovich

unread,
Jun 16, 2014, 2:39:56 AM6/16/14
to devo...@googlegroups.com
Есть еще hangops_ru, где раз в пару месяцев люди собираются в интернетах поговорить, вы легко можете поспрашивать их о том, как все устроено у них.

https://plus.google.com/communities/114229108523474610285

Timur Batyrshin

unread,
Jun 16, 2014, 3:30:08 PM6/16/14
to devo...@googlegroups.com
Если у вас пока 5 человек и ничего не ясно, вам не о масштабировании надо задуматься (если, конечно, не руководство сказало "завтра масштабируемся"), а о том как в том, что есть порядок навести.
Могу предположить, что одним из первых шагов нужно definition of done для задач поменять (включить туда доки, мониторинг, бекапы и все прочее, что к этому относится) и не переходить к следующей, пока эта полностью не выполнена. Первое время будет ломка и производительность упадет, это нужно пересидеть.
Потом review задач ввести — после того как работу по задаче завершил, любой другой человек из команды должен сделанную работу проглядеть и сказать, что все в порядке (с учетом выбранного вами раньше definition of done). Дальше и другие практики обнаружатся.
Не получается всем сразу — начать с себя, остальных тоже можно ненавязчиво к тому же подводить.

воскресенье, 15 июня 2014 г., 0:19:01 UTC+4 пользователь Evgeny Tarasov написал:

Evgeny Tarasov

unread,
Jun 17, 2014, 2:04:30 PM6/17/14
to devo...@googlegroups.com
Совершенно согласен, очень крутая практика! И в итилях её не находил :-)

Я бы ещё в definition of done добавил возможность пересоздать с нуля по документации и/или puppet/chef/ansible. И уточнил бы требование чтобы в доках и/или скриптах были описаны все стандартные действия: добавление/удаление юзеров, ключей, записей и т.д, поднятие/выключение серверов, создание пакетов, релиз и откат кода и т.п.

понедельник, 16 июня 2014 г., 23:30:08 UTC+4 пользователь Timur Batyrshin написал:

Evgeny Tarasov

unread,
Jun 17, 2014, 2:07:39 PM6/17/14
to devo...@googlegroups.com
Спасибо за информацию, вступил.

понедельник, 16 июня 2014 г., 10:39:56 UTC+4 пользователь Ivan Evtuhovich написал:

Timur Batyrshin

unread,
Jun 18, 2014, 4:55:29 AM6/18/14
to devo...@googlegroups.com
Идея в том, что если помечаем задачу завершенной, к ней больше не возвращаемся (в т.ч. для документирования, peer review и т.д).
Включаем все, что для этого нужно, но не больше, иначе есть риск задачу никогда не закрыть.
Что включать, а что нет — нужно смотреть по месту, в зависимости от ваших требований.

вторник, 17 июня 2014 г., 22:04:30 UTC+4 пользователь Evgeny Tarasov написал:

Evgeny Tarasov

unread,
Jun 29, 2014, 1:33:10 PM6/29/14
to devo...@googlegroups.com
Ещё раз привет :-)

Если кому-нибудь интересно, вот тут есть маленький бложек, одна из тем которого - IT Ops management - http://dev117.livejournal.com/


пятница, 6 июня 2014 г., 19:53:18 UTC+4 пользователь Evgeny Tarasov написал:
Привет Devopsru!
Reply all
Reply to author
Forward
0 new messages