Комментарии 17
>>SPA-рейтинг от 1/60
Такая строчка означает один сервер на 60 админов. Если я правильно помню, вам нужна запись вида 60:1 (читается как 60 к 1-му).
Такая строчка означает один сервер на 60 админов. Если я правильно помню, вам нужна запись вида 60:1 (читается как 60 к 1-му).
У нас техподдержка как-то получается многочисленнее
— игнорирование инструкций. Даже когда оборудование от одного вендора и он поставляет достаточно развитую документацию ее никто не читает. troubleshooting guide — игнорируется. У буржуев — это документ обязательный в поставке и используемый достаточно хорошо.
— не принято делиться опытом. Могут посоветовать в конкретной ситуации, но целенаправленно учить никто не собирается. У буржуев — пинают вендора на курсы, собираются сами.
— не принято использовать хорошие но и платные тулзы для сбора информации и анализа. Не докупают дополнения для автоматизации, мониторинга и сбора статистики. Не используют сторонние тулзы. Если что и используется — как правило это самописное или свободное, работающее при этом на половину-треть от полных возможностей.
— игнорирование инструкций. Даже когда оборудование от одного вендора и он поставляет достаточно развитую документацию ее никто не читает. troubleshooting guide — игнорируется. У буржуев — это документ обязательный в поставке и используемый достаточно хорошо.
— не принято делиться опытом. Могут посоветовать в конкретной ситуации, но целенаправленно учить никто не собирается. У буржуев — пинают вендора на курсы, собираются сами.
— не принято использовать хорошие но и платные тулзы для сбора информации и анализа. Не докупают дополнения для автоматизации, мониторинга и сбора статистики. Не используют сторонние тулзы. Если что и используется — как правило это самописное или свободное, работающее при этом на половину-треть от полных возможностей.
— у нас развернуто Wiki, инструкции размещаем там;
— молодняк" попадающий в подразделение, обычно спрашивает других сотрудников как сделать что-либо, если уже есть информация в вики — «деды» отсылают именно туда. Если информации по данной проблеме нет, то после решения проблемы в обязательном порядке решение вносится в вики;
— используем nagios, munin, + ряд самописных утилит (или «костылей», кому как). База данных (она же и CMDB) используется также своя, в ней реализован учет движения оборудования, ремонты, профилактики, учет ПО).
— молодняк" попадающий в подразделение, обычно спрашивает других сотрудников как сделать что-либо, если уже есть информация в вики — «деды» отсылают именно туда. Если информации по данной проблеме нет, то после решения проблемы в обязательном порядке решение вносится в вики;
— используем nagios, munin, + ряд самописных утилит (или «костылей», кому как). База данных (она же и CMDB) используется также своя, в ней реализован учет движения оборудования, ремонты, профилактики, учет ПО).
— есть ли в этом вики последовательность действий по обнаружению и устранению неисправностей? 80-90% проблем стандартные. Как часто информация правиться т.е. какова прогнозируемая вероятность ошибки в доках?
— есть ли у вас курсы повышения квалификации, экзамены и уровни привязанные к зарплате, стимулируется ли сертификация, есть ли оффициальный уровень «гуру» обязывающий обучать и отвечать за молодняк. там еще много такого :)
— если не ошибаюсь собственно fault management, анализирующего аварии и определяющего источник в перечисленном нет. CMDB — configuration management? Какой размер сети, сколько вендоров и как часто вы правите CMDB и/или правите конфиги ручками? Насколько стандартные действия автоматизированы? Что вы делаете если клиент желает нестандартного?
Судя по всему уровень у вас достаточно высок что бы понять что проблемы есть. Вот только путь что вы проходите самостоятельно, наступая на уже известные грабли, пройден другими многократно. Но видимо это карма.
Буржуйские цифры получаются не просто так. Они умеют понимание что плохой саппорт — это потерянные деньги. Но квалифицированный инженер стоит дорого и лучше потратиться на планирование инфраструктуры у специалистов, купить ПО и интегрировать его, стандартизировать и автоматизировать все что можно только бы специалисту не тратить время на рутину. А рутины — 80-90% и если ее убрать то ratio сразу увеличиваются на порядок.
— есть ли у вас курсы повышения квалификации, экзамены и уровни привязанные к зарплате, стимулируется ли сертификация, есть ли оффициальный уровень «гуру» обязывающий обучать и отвечать за молодняк. там еще много такого :)
— если не ошибаюсь собственно fault management, анализирующего аварии и определяющего источник в перечисленном нет. CMDB — configuration management? Какой размер сети, сколько вендоров и как часто вы правите CMDB и/или правите конфиги ручками? Насколько стандартные действия автоматизированы? Что вы делаете если клиент желает нестандартного?
Судя по всему уровень у вас достаточно высок что бы понять что проблемы есть. Вот только путь что вы проходите самостоятельно, наступая на уже известные грабли, пройден другими многократно. Но видимо это карма.
Буржуйские цифры получаются не просто так. Они умеют понимание что плохой саппорт — это потерянные деньги. Но квалифицированный инженер стоит дорого и лучше потратиться на планирование инфраструктуры у специалистов, купить ПО и интегрировать его, стандартизировать и автоматизировать все что можно только бы специалисту не тратить время на рутину. А рутины — 80-90% и если ее убрать то ratio сразу увеличиваются на порядок.
— для ключевых и сложных сервисов есть. Где-то раз в полгода устраиваем ревизии;
— в прошлом году были, в этом — «зарезали». «Гуру» — да, обучают. Остальное — грейды, поддержка сертификации и т.п. — отсутствует;
— м-м-м, конечно, в wiki fault management отсутствует. Есть сенсоры (nagios, munin), выстроена зависимость сервисов. При сигнале от сенсора проводятся мероприятия по устранению. Например, отработка ситуации когда уровень свободного места на разделе переходит отметку «warning» выполняется администраторами в штатном режиме.
Хм, размер сети… что вы под этим подразумеваете? количество узлов? Около 700… Конфиги правятся руками, затем автоматом собираются и коммитятся в SVN. diff'ы для контроля падают группе поддержки сети и телекоммуникаций.
Конечно проблемы есть, когда в ИТ (а уж тем более в эксплуатации ИТ) не было проблем? Имел «удовольствие» некоторое время назад поработать с HP NNM и привязанном к нему ServiceDesk. Категорически не понравилось. Более того, не увидел систем управления ИТ-ресурсами отражающих российскую специфику — учет ОС, номенклатурные номера, история владения и т.п. Поэтому было принято решение делать свое (2008 год). Естественно, т.к. система писалась под наши (узко локальные) задачи, там нет многих вещей из ITIL. Например, управление мощностями отсутствует.
Абсолютно с вами согласен. Как мне кажется, мы (я сейчас не про свое предприятие, а вообще, про отрасль) отстаем лет 5 не больше в области управления ИТ, если брать крупный бизнес, и лет 7 если брать средний. Еще 5 лет назад никто, по большому счету, не заморачивался лицензированием ПО, анализом разношерстных конфигураций (что ПО, что железа) — то откуда возьмется понимание, что бизнес теряет деньги на буксующем, из-за разношерстности применяемых решений, ИТ-саппорте? Далеко ходить не буду — у нас у самих 250(!) моделей системных блоков. Ладно, держимся внутри платформы Intel, за счет этого чуть легче, но тем не менее…
— в прошлом году были, в этом — «зарезали». «Гуру» — да, обучают. Остальное — грейды, поддержка сертификации и т.п. — отсутствует;
— м-м-м, конечно, в wiki fault management отсутствует. Есть сенсоры (nagios, munin), выстроена зависимость сервисов. При сигнале от сенсора проводятся мероприятия по устранению. Например, отработка ситуации когда уровень свободного места на разделе переходит отметку «warning» выполняется администраторами в штатном режиме.
Хм, размер сети… что вы под этим подразумеваете? количество узлов? Около 700… Конфиги правятся руками, затем автоматом собираются и коммитятся в SVN. diff'ы для контроля падают группе поддержки сети и телекоммуникаций.
Конечно проблемы есть, когда в ИТ (а уж тем более в эксплуатации ИТ) не было проблем? Имел «удовольствие» некоторое время назад поработать с HP NNM и привязанном к нему ServiceDesk. Категорически не понравилось. Более того, не увидел систем управления ИТ-ресурсами отражающих российскую специфику — учет ОС, номенклатурные номера, история владения и т.п. Поэтому было принято решение делать свое (2008 год). Естественно, т.к. система писалась под наши (узко локальные) задачи, там нет многих вещей из ITIL. Например, управление мощностями отсутствует.
Абсолютно с вами согласен. Как мне кажется, мы (я сейчас не про свое предприятие, а вообще, про отрасль) отстаем лет 5 не больше в области управления ИТ, если брать крупный бизнес, и лет 7 если брать средний. Еще 5 лет назад никто, по большому счету, не заморачивался лицензированием ПО, анализом разношерстных конфигураций (что ПО, что железа) — то откуда возьмется понимание, что бизнес теряет деньги на буксующем, из-за разношерстности применяемых решений, ИТ-саппорте? Далеко ходить не буду — у нас у самих 250(!) моделей системных блоков. Ладно, держимся внутри платформы Intel, за счет этого чуть легче, но тем не менее…
Простите, так серверов на админа, или IT техники на админа?!
Очень тяжело этими цифрами оперировать… Особенно в крупном масштабе.
Ну вопрос — вы каких администраторов считали? Сетевых? Занимающихся инфраструктурой или, собственно, приложениями на сервере? Это разные люди и у них разная область работы.
Ну вопрос — вы каких администраторов считали? Сетевых? Занимающихся инфраструктурой или, собственно, приложениями на сервере? Это разные люди и у них разная область работы.
Группа администрирования — 3 человека. Занимаются администрированием серверов, системного и прикладного ПО на них.
Группа поддержки пользователей (рабочих станций и ПО, сетей связи и клиенсткой телефонии) — 4 человека.
Группа поддержки пользователей (рабочих станций и ПО, сетей связи и клиенсткой телефонии) — 4 человека.
В данном конкретном случае. Чуть меняются конфигурации — меняется обслуживающий персонал.
Я к тому, вто это рассуждение очень локальное.
Я к тому, вто это рассуждение очень локальное.
приведите пример, пожалуйста.
Ну, смотрите: сетями должен заниматься отдельный человек, правильно? (не, я понимаю, что завхоз-электрик может заниматься и компьютерами немножко, но мы-то о профессионалах, так?) Базами данных — другой. SAN/NAS — третий. Инфраструктурой виртуализации/платформами четвёртый. Рутинными работами по обслуживанию ПО и серверов — пятый. Планированием инфраструктуры — шестой. И т.д.
Чуть-чуть меняются акценты — и количество и специализация людей в команде меняется. Так что считать посерверно… Это примерно как программистов по количеству строчек кода оценивать.
Чуть-чуть меняются акценты — и количество и специализация людей в команде меняется. Так что считать посерверно… Это примерно как программистов по количеству строчек кода оценивать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Admins-per-server ratio — наблюдения из собственного опыта