--
Вы получили это сообщение, поскольку подписаны на группу "devopsru".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес devopsru+u...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
--
On Sat, Jun 14, 2014 at 01:19:01PM -0700, Evgeny Tarasov wrote:это значит плохие админы, программисты и жадное руководство.
> Помимо этого мне приходилось видеть много случаев когда системное
> администрирование это очень нагруженная и связанная с сильным стрессом
> деятельность, в результате у которой всё равно низкий аптайм, постоянные
> мелкие и крупные проблемы и очень много драмы как на стороне сисадминов так
> и на стороне пользователей. Мне очень интересно было бы услышать про опыт
> других людей.
> По поводу бюрократии - многие методологии предписывают кучу процессов и50 человек и все понимают сложную систему?
> тому подобной менеджерской деятельности. Возможно ли существование
> высокопроизводительной организации IT Operations без оверхэда на процессы,
> бюрократию, чтобы всё было просто и гибко, чтобы все задачи можно было
> просто брать и делать, и чтобы процесс масштабировался на 5-10-50 человек,
> и у каждого было понимание системы, и чтобы ничего не ломалось
> часто,
ну я не знаю.
Мои пять копеек.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:это значит плохие админы, программисты и жадное руководство.
> Помимо этого мне приходилось видеть много случаев когда системное
> администрирование это очень нагруженная и связанная с сильным стрессом
> деятельность, в результате у которой всё равно низкий аптайм, постоянные
> мелкие и крупные проблемы и очень много драмы как на стороне сисадминов так
> и на стороне пользователей. Мне очень интересно было бы услышать про опыт
> других людей.
Я бы убрал слово "плохие". Тут ошибка, по моему мнению, исключительно руководства, что они не видят проблемы и нанимают людей, которые не соответствуют уровню решаемых задач, не вкладывают ресурсы в развитие команды и образование сотрудников.
> По поводу бюрократии - многие методологии предписывают кучу процессов и50 человек и все понимают сложную систему?
> тому подобной менеджерской деятельности. Возможно ли существование
> высокопроизводительной организации IT Operations без оверхэда на процессы,
> бюрократию, чтобы всё было просто и гибко, чтобы все задачи можно было
> просто брать и делать, и чтобы процесс масштабировался на 5-10-50 человек,
> и у каждого было понимание системы, и чтобы ничего не ломалось
> часто,
ну я не знаю.Здесь я согласен, так не может быть в принципе. Тут как раз задача стоит, как построить взаимодействие так, чтобы каждый из 50 знал, кого и о чем спрашивать, и имел не так много возможностей "все сломать", при этом чтобы у него осталось много возможностей что-то сделать, не натыкаясь каждый раз на отсутсвтие прав доступа и сложные бюррократические процедуры согласования/разрешения. И где лежит этот баланс и какой он — сильно зависит от многих факторов.
Я бы убрал слово "плохие". Тут ошибка, по моему мнению, исключительно руководства, что они не видят проблемы и нанимают людей, которые не соответствуют уровню решаемых задач, не вкладывают ресурсы в развитие команды и образование сотрудников.
А бывают ли вообще случаи в дикой природе, когда админы и программисты отличные, руководство грамотное и не жадное. Когда админы работают с полной самоотдачей и получают реальные осязаемые результаты и явный положительный фидбэк, руководители делают всё как надо, а пользователи счастливы ?
> По поводу бюрократии - многие методологии предписывают кучу процессов и50 человек и все понимают сложную систему?
> тому подобной менеджерской деятельности. Возможно ли существование
> высокопроизводительной организации IT Operations без оверхэда на процессы,
> бюрократию, чтобы всё было просто и гибко, чтобы все задачи можно было
> просто брать и делать, и чтобы процесс масштабировался на 5-10-50 человек,
> и у каждого было понимание системы, и чтобы ничего не ломалось
> часто,
ну я не знаю.Здесь я согласен, так не может быть в принципе. Тут как раз задача стоит, как построить взаимодействие так, чтобы каждый из 50 знал, кого и о чем спрашивать, и имел не так много возможностей "все сломать", при этом чтобы у него осталось много возможностей что-то сделать, не натыкаясь каждый раз на отсутсвтие прав доступа и сложные бюррократические процедуры согласования/разрешения. И где лежит этот баланс и какой он — сильно зависит от многих факторов.
Именно!
Привет Devopsru!