ITIL

[Evgeny Tarasov]

Привет Devopsru!

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

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

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

[Timur Batyrshin]

А какую задачу бизнеса вы пытаетесь решить при помощи ITIL, и какой размер организации?

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

Это можно делать при помощи ITIL (формализация процессов), Agile (форсирование личного обмена опытом между

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

Что применять — сильно зависит от размера, специфики работы организации, уровня (технического, культурного и т.д) сотрудников

и управления и многого другого.

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

использоваться и по-отдельности, если они решат вашу какую-то конкретную задачу.

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

[Evgeny Tarasov]

Спасибо вам за ваш ответ!

Я использую 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]

> Может ли кто-нибудь поделиться опытом работы в компании, где всё это поставлено на высоком уровне и нет хронических проблем?

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

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

--
Best regards,
Koldaev Anton

[Ivan Evtuhovich]

Евгений, вам проще будет прийти на одну из тусовок и поговорить с коллегами в неформальной обстановке, чтобы они рассказали, как весь процесс устроен у них.

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

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

--

[Slawa Olhovchenkov]

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]

Мои пять копеек.

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]

On Sun, Jun 15, 2014 at 11:08:43PM +0400, Ivan Evtuhovich wrote:

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

> согласования/разрешения. И где лежит этот баланс и какой он - сильно
> зависит от многих факторов.

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

[Evgeny Tarasov]

Иван, в нашей провинции не так уж и много профильных тусовок :-)

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

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

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

[Evgeny Tarasov]

воскресенье, 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]

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

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

[Slawa Olhovchenkov]

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]

ну можем получить еще вариант -- никто не разбирается во всём.
документация -- устарела/не соответсвует действительности.
пользователь по процедуре гоняется по кругу.
ради копеешной проблемы собирается семь телефонных совещаний с
клиентом по два часа.
результат -- хуй.
зато ИБД в полный рост. и наверняка ITIL соответсвует и ISO9001 тоже.

[Evgeny Tarasov]

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

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

[Ivan Evtuhovich]

Доброе утро.

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

А бывают ли вообще случаи в дикой природе, когда админы и программисты отличные, руководство грамотное и не жадное. Когда админы работают с полной самоотдачей и получают реальные осязаемые результаты и явный положительный фидбэк, руководители делают всё как надо, а пользователи счастливы ?
 

Конечно нет, как и любая идеальная концепция, это направление, куда стоит стремиться. Для каждого конкретного бизнеса задача лишь сделать, чтобы IT работало эффективнее, чем "в среднем по рынку", чтобы получить конкурентное преимущество.

 

 

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

50 человек и все понимают сложную систему?
ну я не знаю.

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

Именно!

 

 

[Ivan Evtuhovich]

Есть еще hangops_ru, где раз в пару месяцев люди собираются в интернетах поговорить, вы легко можете поспрашивать их о том, как все устроено у них.

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

[Timur Batyrshin]

Если у вас пока 5 человек и ничего не ясно, вам не о масштабировании надо задуматься (если, конечно, не руководство сказало "завтра масштабируемся"), а о том как в том, что есть порядок навести.

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

Потом review задач ввести — после того как работу по задаче завершил, любой другой человек из команды должен сделанную работу проглядеть и сказать, что все в порядке (с учетом выбранного вами раньше definition of done). Дальше и другие практики обнаружатся.

Не получается всем сразу — начать с себя, остальных тоже можно ненавязчиво к тому же подводить.

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

[Evgeny Tarasov]

Совершенно согласен, очень крутая практика! И в итилях её не находил :-)

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

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

[Evgeny Tarasov]

Спасибо за информацию, вступил.

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

[Timur Batyrshin]

Идея в том, что если помечаем задачу завершенной, к ней больше не возвращаемся (в т.ч. для документирования, peer review и т.д).

Включаем все, что для этого нужно, но не больше, иначе есть риск задачу никогда не закрыть.

Что включать, а что нет — нужно смотреть по месту, в зависимости от ваших требований.

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

[Evgeny Tarasov]

Ещё раз привет :-)

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

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

Привет Devopsru!