Комментарии 13
У всех есть много скелетов в шкафу в связи с мониторингом, но я горжусь, что в наших системах, помимо скелетов умершего техдолга, есть достаточно много проверок, дающих несколько warning/critical в неделю, которые устраняются до того, как задевают клиента. Не то, чтобы это было всегда и во всём, но само наличие таких штук — гордость.
Мониторящих инженеров тоже 10?
Если честно, я не знаю размера нашего operations, но он довольно эффективен — инсталляций у нас сильно больше, чем инженеров operations team.
Как получается не увеличивать операционщиков при расширении парка? Эта зависимость — почти линейная.
Она линейная, если работа операционного отдела не оптимизируется. Если выделить чуть-чуть времени на оптимизацию самой частой операции операционного отдела (сама операция меняется от захода к заходу, упор на «самую частую за последнее время»), то кривая становится ближе к логарифмической. Постоянно нужно вкладывать константное количество усилий на автоматизацию и оптимизацию всё большего потока событий. В идеальном мире это кривая костантная прямая (т.е. оптимизируются всё), но в реальном мире растёт число плохооптимизируемых процессов. К счастью, они растут медленнее, чем количество инсталляций.
А по мере роста числа инсталляций некоторые плохооптимизируемые процессы становятся настолько существенными, что можно выделить больше ресурсов на их решение.
PS Надо различать operations и on-site. Замена жёстких дисков, увы, процесс физиологический и требует от реального человека потыкать сервер. Зато задачу на замену диска и всё софтовое после замены (файловая система и т.д.) может сделать робот. Сам.
А по мере роста числа инсталляций некоторые плохооптимизируемые процессы становятся настолько существенными, что можно выделить больше ресурсов на их решение.
PS Надо различать operations и on-site. Замена жёстких дисков, увы, процесс физиологический и требует от реального человека потыкать сервер. Зато задачу на замену диска и всё софтовое после замены (файловая система и т.д.) может сделать робот. Сам.
На практике получается, чтобы кривая была логарифмическая, необходимо просто «грузить» ИТ персонал больше, сделать, например из одной позиции — 2, а то и 3. Непокорных — выгнать. Тогда, вероятно ваши слова имели бы смысл. Но возможно просто у меня такой стереотип об оптимизации. Во всех конторах где я трудился — не важно какой там CIO — имбицил или спец с XX-летним стажем, оптимизация начинается именно с «нагружания» персонала, а тут, как ни крути и 12-ти часовой рабочий день, и выгорание, и даже пьянство на рабочем месте (не я сам, но приходилось у коллег и такое наблюдать) и все остальное. Получилось ли у Вас сделать так, чтобы и волки были целы (оптимизировать ИТ) и овцы целы (чтобы админы не расползлись в другие конторы)?
Очевидно, что для выделения 20% времени персонала на автоматизацию, эти 20% можно сделать одним из трёх видов: добавить персонала, уменьшить operational нагрузку на персонал или увеличить общую нагрузку (добавить 20%). Это как с капитальными инвестициями. Их можно делать за счёт заёмных средств (с надеждой, что отобъётся), можно за счёт собственных средств (забирая оборотные средства), а можно за счёт снижения прибыли (выплат акционерам/владельцам).
С практической точки зрения на уровне микроменеджмента, этот вопрос решается подбором кадров — обычно те, кто умеют автоматизировать, либо прагматичны и хотят за это много денег (и тогда делают ровно то, что их попросят), либо рок-звёзды (денег меньше, зато надо мириться с их архитектурными и технологическими предпочтениями), либо нерды (и тогда надо отдельного человека для трансляции их умной работы в business value).
Во время текучки кадров на следующую позицию искать человека, у которого в обязанностях с самого начала будет заявлена автоматизация, и дальше с такого человека спрашивать на 50% за автоматизацию (а не только на operation).
С практической точки зрения на уровне микроменеджмента, этот вопрос решается подбором кадров — обычно те, кто умеют автоматизировать, либо прагматичны и хотят за это много денег (и тогда делают ровно то, что их попросят), либо рок-звёзды (денег меньше, зато надо мириться с их архитектурными и технологическими предпочтениями), либо нерды (и тогда надо отдельного человека для трансляции их умной работы в business value).
Во время текучки кадров на следующую позицию искать человека, у которого в обязанностях с самого начала будет заявлена автоматизация, и дальше с такого человека спрашивать на 50% за автоматизацию (а не только на operation).
Вот о том я и говорю — берется как правило 3-й вариант — увеличить общую нагрузку, только как правило она увеличивается не на 20%, а скажем, от 100% и выше. Кстати, чем меряете те 20%? Часами, KPI-ями, кол-вом закрытых инцидентов/тикетов? В реалии нигде не сталкивался с грамотным просчетом таких цифр, зачастую они просто берутся с потолка, никто со сбором статистики не парится особо, т.к. ее сбор (внезапно) тоже ресурсоёмок. Итог — одна позиция пашет как минимум за 2-х, в том числе и за те 20% оптимизатора. Не забываем, что операционка далеко не статична и тоже растет (как это модно называть — расширяются компетенции сотрудника/отдела, условно — работал человек эникеем — на ему ВЭБ-сайт и АТС-ку в операционную нагрузку — профит — сэкономили на вэбдизайнере (сайт-админе) и телефонисте (инфраструктурном админе), теперь админ может заниматься оптимизацией, но нагрузка а эникея возросла минимум на 100% и так что 2-й вариант тоже не вариант, операционка не уменьшается никогда — это аксиома, за исключением «схлопывания» конторы. Я уже 3-й раз переживаю за свою карьеру подобное «расширение компетенций», реально уже бесит такой подход сверху. Как-то хочется не допускать такого обращения с собой, но вероятно, мне не хватает опыта правильно сказать «Нет!» руководству и чтобы после этого не было последствий (без выговоров, матов и мордобоя). Первый также вариант отпадает — расширять ИТ-персонал никто не будет, по крайней мере до того как, человек, работающий за 3-х, не пошлет работодателя, когда на него соберутся вешать очередную операционку 4-го человека. Было — проходили, во все конторы после моего ухода берут минимум 2 человека, т.к. один новый человек со старта просто тупо не потянет тот пул операционки.
В такой компании не может быть системной автоматизации. Почему? Потому что им нечего автоматизировать. Отдать на аутсорс всё хозяйство, да и всё.
Автоматизация подразумевает существенный фронт работ, и процессы, которые можно автоматизировать. Как можно автоматизировать работу эникея, у которого половина работы — общение с людьми? Засунуть всё в трекер? Это не автоматизация, это организационные изменения и к автоматизации не имеет отношения.
Вообще, малый энтерпрайз образца 2000ых (своя АТС, свой веб-сайт на своих мощностях, свой админ с AD, принтерами, рабочими станциями, свой почтовый сервер, свой колхозный ДЦ, возможно, своё видеонаблюдение) — это тупиковый путь. Хотя и отличный карьерный трамплин для тех, кто оказывается в таких конторах в качестве админа в первый раз. (Но главное свойство трамплина — либо он тебя подкидывает, либо ты слетаешь с него в какую-то дыру — т.е. это не работа на пол-жизни).
Автоматизация подразумевает существенный фронт работ, и процессы, которые можно автоматизировать. Как можно автоматизировать работу эникея, у которого половина работы — общение с людьми? Засунуть всё в трекер? Это не автоматизация, это организационные изменения и к автоматизации не имеет отношения.
Вообще, малый энтерпрайз образца 2000ых (своя АТС, свой веб-сайт на своих мощностях, свой админ с AD, принтерами, рабочими станциями, свой почтовый сервер, свой колхозный ДЦ, возможно, своё видеонаблюдение) — это тупиковый путь. Хотя и отличный карьерный трамплин для тех, кто оказывается в таких конторах в качестве админа в первый раз. (Но главное свойство трамплина — либо он тебя подкидывает, либо ты слетаешь с него в какую-то дыру — т.е. это не работа на пол-жизни).
И еще — нельзя просто так взять и начать оптимизацию ®. Для нее нужны ресурсы — но ни менеджмент, ни проектировщики, ни аналитики, а банально руки и мозги админов.
Именно. Хорошая автоматизация operation'а идёт по одному из двух направлений: автоматизация снизу (себе сделали удобно) и автоматизация сверху (начальство себе сделало удобно). Оба варианта имеют право на существование, но автоматизация снизу обычно даёт количественное улучшение, а автоматизация сверху — качественное.
Вы эти показатели считаете как-то автоматом или вручную по каждому крупному инциденту?
Если автоматом, то хотелось бы подробнее узнать как, особенно по detection.
Если автоматом, то хотелось бы подробнее узнать как, особенно по detection.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анатомия инцидента, или как работать над уменьшением downtime