Comments 21
Чтобы выполнять дополнительную работу: осваивать новый для себя процесс, вести документацию и т.д., требуется время. А время у нас обычно уже и так занято. Т.е. нужны дополнительные люди, которым придется платить дополнительные деньги.
Так что в теории все хорошо, а на практике тебе дают студента с наказом "вот тебе человек, научи его всему, только чтобы он ничего не сломал". Ещё и KPI поднимают вдвое, ты же теперь с "помощником". А после обучения его могут у тебя забрать и чем-то самостоятельным нагрузить.
Эксплуатацией обычно интересуются по остаточному принципу, всё же и так работает, причем само по себе.
Обычно тебе дают джуна, который по компетенциям ниже дна, чтобы учил этого барана как хочешь всем своим наработкам, которые потом он будет поддерживать и бегать к тебе по любому вопросу год+, пока ты пилишь новые фичи.
По сути он становится дополнительной бюрократической единицей, создающей видимость работы, но по факту даже воспринимать и без искажений транслировать далее информацию не способен.
Когда на выходных что-то случилось - он за все выходные не может разобраться в том, что якобы поддерживает год+.
С другой стороны, если суету с коллегами дублерами (родственниками менеджеров, которых пропихнули в ИТ) не разводить, то нормальный специалист среднего уровня без особых проблем разбирается во всем, так как все есть в общем репозитории и Вики.
Хм.
Велосипед 2.0. RACI и DRP с прогонами в зависимости от критичности сервиса.
Чёт у вас странные процессы, и видимо очень странный SRE. В иных домах значительный объем подготавливается до передачи в эксплуатацию. И в случае инцидента во время разбора как раз проверка актуализации всего с аппувами участников RACI.
И владелец сервиса вместе с SRE должны иметь KPI, нет?
Собственно не очень понятно, вы где-то в середине, если не в конце процесса пробуете приклеить пластырь. Исходную проблему вы так и не решаете.
А представьте себе контору, в которой полное отсутствие документации, нет wiki, а ценную информацию работники не передают, а жадностно держат у себя в голове, чтобы не дай бог их ценность не упала. Представили? А я в таком месте работал и это был ад
Еще хуже, когда документацию в таких конторах считают не мастхэвом, который пофиксит сразу несколько проблем, а чем-то второстепенным, типа "кинул в лицо заказчику, чтобы он схавал", а потом идут плаки-плаки, что " Работать некому, синьоры массово бегут, как от бомб, джуны все ломают! ".
Действительно, почему?
Совет: донесите до команды, что ротация — это позитивная практика, что она про развитие и апскил. Если сотрудники не поймут ценности, вовлеченность будет низкая.
Вредительская практика, которая только для эффективной Совы выглядит хорошо, потому что так в методичках написал The Great Owl, чьи догматы высечены в граните. Ротация снижает экспертизу, при ней лучшая тактика это "зачем мне вникать в тонкости, если меня завтра перекинут на другой проект/задачу - сделаю быстрофикс и забуду, следующий пусть думает". При ротации никто ни за что не отвечает, и чем интенсивнее ротация, тем сильнее размазывание ответственности.
Идеально, когда на теме сидит эксперт плюс несколько младших, которых он обучает. Даже если что-то произойдет, на обученых младших вы всегда вывезете в экстренном режиме до прихода нового эксперта.
И здесь важно подчеркнуть: супергерои — это угроза.
В первую очередь он "опасен" тем, что просит нормальную зарплату, а не обязанности лида за з\п джуна. И ему нельзя отказать - уйдет - все полетит к чертям.
Шаг 3. Документируйте процессы.
Эх, хорошо бы... Но чаще всего заказчик не хочет платить за человекочасы на написание доки, тестирование, красивые требования. Его устраивает говнокод, но чтобы быстро. Техдолг? Нет, не слышали, релизьте фичи, а с остальным потом может быть когда нибудь...
Вот и акционеры в панике, когда талантливый CEO один, и никто не может его заменить.
Чтоб не заниматься всеми этими проблемами, надо делать хороший понятный надёжный законченный продукт. Не внедрять бесчисленное количество фич бесконечно.
у меня комбо было😁😁😁
я отвечал за скуд, сервера, счета на услуги, заправка и эксплуатация картриджей, умею здесь и сейчас отремонтировать мамку/бп/ибп/монитор, настроить сеть, телефонию и ещё немного веб-разработкой увлёкся - сделал внутренние сервисы…ииии…случается пересмотр/оптимизация расходов компании - ( замены коллеги-сотрудника небыло у меня)😄😄😄 в один «прекрасный день» мне заявляют что я часто сижу ни чего не делаю, а только прибавку зп прошу, на что говорю радуйтесь пока что Вы не замечаете моей работы ( суеты ).
затаив обиду ухожу в отпуск с мыслью последующего завершения карьеры здесь, и тут в какой-то из дней откл.питания эл. магистрали -> пару коротких запусков-всплесков на линии-> и сгорает ибп и тащит за собой связь скуд и коммутацию офисов, и почему-то рэйд-контроллер в сервере помер( это стало загадкой для меня).
Я в поездке, связи нет, появляюсь в зоне доступности и как посыпались панические сообщения со всех мессенджеров😱😱😱
Что было дальше? На самом интересном месте прервали рассказ.
простите, телефон разряжался, успел отправить большую часть😁🤷🏻♂️ побоялся что ещё и по кол-ву символов превысил.
продолжение:
вышел внепланово из отпуска, пустил напрямую, не через ИБП (ибо экономия/оптимизация😁и АКБ не дали купить ранее), сервер пришлось без рэйда поднять побыстрому, скуд и далее всё починил, коммутацию восстановил.
напомнил про UP-нуть ЗП🙂, предложили +2 к.руб. 🤣🤦♂️ пожал руки, пошёл в кадры за трудовой…
приближалсЯ конец месяца, картриджи не заправлены в запас, интернет и телефония на подсосе, ИБП серверов и коммутации без АКБ, сервер без зеркалирования, 100+ пользователей учатся утилизировать проблемы самостоятельно, подходят сроки обслуживания термоэлементов в печках МФУ…. ну, короче понятно к чему идёт😁
*( оно всё ещё какое-то время будет работать конечно, до следующего всплеска в сети, или до исчерпания ресурса комплектующих )
как потом рассказали приходили кандидаты и крутили пальцем у виска типа это в одного не реально обслуживать, ну и про ЗП сказали чтобы сами учились тогда всё это поддерживать, либо штат ИТ-спецов увеличить. В итоге студенты приходили и уходили… чем закончилось не знаю, информаторы тоже уволились позже🙂
+2 тысячи к зп, ну и смех))
Зачем было в такой конторе так много сил вкладывать?
вполне логичный вопрос 🙂👍
1.мама тут же работала, предпенсионер, на работу/с работы на машине вместе;
2.дети по пути в садик/школу отвезти/забрать;
3.более-менее свободный график.
ну а к финалу, мама - решила пойти на заслуженный отдых, дети - выпуск из садика, второй уже может смотреть за первым💪😁
поэтому ценность места сошла на нет, тем более я за это всё причесал структуру и держал всё в порядке, в конце всего лишь попросил адекватной прибавки, которая возможно и перевесила бы желание уйти, но, 🤷🏻♂️нет, так нет.
Так а чем в итоге всё кончилось?
Потом:
1) Вас уволили за то, что сделали все плохо.
2) Наняли толпу студентов и ойти директора за 10х вашей зарплаты
3) Прошло некоторое время, студенты обучились и разбежались, директор свалил.
4) В конторе появился новый ойти-директор, который просто отсиживает испытательный срок, чтобы перекатиться куда-либо еще. Параллельно с ним бегает новый студент, который отвечает за все, и ему удается поддерживать вот это все.
5) Наступает час Х
6) Колесо сансары делает оборот, и мы в пункте 1.
Пункты 3-4 иногда смешиваются и меняются в причинно-следственных сторонах.
После определенного level-а у героя появляется новая способность предугадывать событие X, и менять место работы в промежутке между пунктами 4-5.
В вашей табличке, насколько я понял, владельцы процессов - это сеньоры, при этом за назначение дублёров они не отвечают. Как им поступать, если им в дублёры назначают сотрудников с недостаточными скиллами или мотивацией (см. также комментарии предыдущих ораторов на эту тему)?
Если важна заменяемость, почему бы не перенести владение процессом к руководителю этих сеньоров (и пусть они выполняют процессы по очереди/по расписанию дежурств (см. также замечание выше про улучшение процессов исполнителями)?
...
Вообще, приведённые примеры странные - кажется, что они не про "выстреливший" bus factor, а про управление компетенциями/ресурсами:
Ушел единственный DevOps-инженер, который знал конфигурацию отказоустойчивости кластера. Кластер упал при обновлении, подняли только через 36 часов.
Т.е. кто-то "не зная броду" (не изучив предварительно систему и не придумав плана действий) и не "подстелив соломки" (не расписав планов отката) полез и был допущен шатать кластер? Кажется, что проблема в выборе соответствующего сотрудника (либо в манипулятивном принуждении его к действию несмотря на его активные возражения).
Специалист по Oracle уволился, не передав доступы к мониторингу.
Если мониторинг на bare metal, то неспособность получить креды - это признак низкой квалификации SRE, а если в облаке или в среде со специализированной защитой - признак плохой работы техдира/ИБ.
Новая команда поддержки не могла найти документацию по старому сервису.
А старую куда дели? Судя по слову "команда", этот пример - точно не про bus factor...
Инженер заболел, но только у него был договор с подрядчиком на оборудование.
Контекст данного кейса маленький. Но инженер в данном случае, получается, был не только инженером (а неким аналогом биг босса, умеющим в инженерию), либо, опять же, вопрос к руководству/ИБ.
У МТС есть такая странная штука - NB-IoT. О ней у разных операторов, работавших с ней, кардинально разное мнение. Один считает что надо заполнить заявку, второй что надо придти в особый офис, кто то считает что запросить можно но в данный момент симкарт нет, кто то уверен что они есть, и т.д. Где заявленный процесс передачи данных и знаний?
Другой пример - что то не работает. Никто никогда точно не скажет почему, вы не знаете работает у вас оборудование или нет. На вопросы о тарифах даются неправильные ответы (пример - роуминг в Абхазии).
Он у вас один не потому, что не хочет делегировать, а потому что остальные не хотят работать, найдут одного, сядут на шею, ноги светят и едут пока везёт.
«Один ушел — и все сломалось». Почему в ИТ-эксплуатации важно отслеживать Bus Factor и как это делаем мы