Вот-вот в нашу жизнь ворвутся чудеса и новые надежды - Новый 2017 год!
Но пока рабочие будни и проектная суета не отпускают нас, в жизни itSMF России произошло знаменательное событие.
Благодаря усердному труду наших коллег: Антона Лыкова, Андрея Косыгина, Алексея Ламыкина, Елены Шушковской, Константина Нарыжного, Степана Хрулева, Антона Алексеева, Александра Цимбалистова, Натальи Новоселовой, Романа Журавлева, Сергея Конакова, Татьяны Орловой, Елены Карабановой в мир ITSM вошла книга ITIL Foundation Handbook на русском языке.
Все азы и основы стали доступнее (а членам itSMF ещё и со значительной скидкой)
С 19 декабря книгу можно заказать в интернет-магазине издательства TSO (The Stationery Office)
Всем причастным — мои благодарность и поздравление.
Компьютеры и компьютерщики жили без Айтиля 44 года: ENIAC работал уже в 1945, а первый том первой версии Айтиля вышел только в 1989 году. Писать этот том начали в 1986, значит, идея написания появилась ещё раньше. Что случилось с компьютерами в середине 80-х такого, что в ответ на это пришлось написать Айтиль?
Не случилось ничего. Самое близкое к 1986 году заметное событие в компьютерной индустрии — уход Стива Джобса из «Эпл» в 1985 году. Перед этим он выпустил «Макинтош» в 1984. Перед этим IBM выпустила PC в 1981. Да, персональные компьютеры изменили мир, но ни одно из этих событий не могло быть причиной написания Айтиля. Во-первых, в Айтиле не написано об особой роли персональных компьютеров. Наоборот, в версии от 2000 года авторы всё ещё пишут про мейнфреймы, как про ядро инфраструктуры. Во-вторых, известно, что на создание Айтиля сильно повлияла созданная в IBM «Архитектура управления информационными системами» (ISMA), первый том которой вышел в 1980 году. Работа над ISMA началась в 1972. Но и в начале 70-х с компьютерами ничего выдающегося не произошло. Как будто Айтиль написали от нечего делать. А ведь так не бывает! Что-то должно было послужить причиной.
Раньше почти все сотрудники ИТ были программистами
В 1995 году мы с одногруппниками обсуждали, кто такой хороший программист. В деталях разошлись, но суть все понимали одинаково: хороший программист это тот, кто пишет хорошие программы. Это логически следовало из того, кто такой программист вообще — это тот, кто пишет программы.
Через год я уже работал программистом, переписывал на ФоксПро заводскую систему расчёта потребности в материалах и запчастях. Мой друг этажом ниже писал на Паскале систему учёта готовой продукции. Рядом с ним программировали систему расчёта зарплаты. Почти все сотрудники отдела АСУ были программистами, то есть писали программы.
Из определения, что программист — это тот, кто пишет программы, следует, что когда программы написана, его работа закончена. На заводе было не так: после написания программы её нужно было установить, обучить пользователей, решать их проблемы. У заводского программиста неожиданно оказалось множество непрограммистских обязанностей.
В 2015 году я искал и расспрашивал людей постарше о том, как работали отделы АСУ в прошлом. Свидетелей 60-х и 70-х не нашёл, а в 80-х было то же самое: несмотря на попытки министерств распространять готовые программы по подведомственным предприятиям, несмотря на попытки предприятий распространить свое ПО на другие предприятия, на заводах и в конторах программисты старались не использовать чужие программы, но писать свои. А написав, сопровождали и поддерживали их.
За границей дела обстояли точно так же: например, Ф. Брукс в «Мифическом человеко-месяце» говорит об ИТ-подразделении только как о команде программистов, а идею покупать готовое ПО, а не разрабатывать собственное, называет революционной. Книга вышла в конце 60-х.
Помню, в конце 90-х молодые сотрудники ИТ-отделов потешались над бухгалтерами за то, что те называли их программистами. А ведь с точки зрения бухгалтера ничего не изменилось: много лет к бухгалтеру приходил сотрудник ИТ-отдела, чтобы «помочь с программой». И всегда раньше этот сотрудник был программистом, по должности и по выполняемой работе. А когда в конце 90-х сотрудник ИТ-отдела точно так же пришёл к бухгалтеру, чтобы «помочь с программой», с чего бухгалтер должен был захотеть называть его не программистом, а как-то иначе?
В 2000-х в ИТ-подразделениях программистов не стало
Бухгалтер не знал, что революционная идея конца 60-х покупать готовое ПО, а не писать собственное, к концу 90-х полностью реализовалась. Типовая инфраструктура небольшой компании выглядела так: на рабочих местах ОС и офисный пакет от «Микрософта», плюс бухгалтерская программа от российского производителя. На серверах ещё держался «Новелл», но «Микрософт» его уверенно вытеснял. Компании покрупнее могли похвастаться более престижными марками серверов, а бухгалтерская программа у них была немецкая, но собственных программ ни большие, ни маленькие компании не писали.
Программисты оказались не нужны, и за несколько лет ИТ-подразделениям пришлось превратиться из команд разработчиков в команды эксплуатации и поддержки. Молодые айтишники 2000-х правильно не понимали, за что их называют программистами, потому что в отделах, где они работали, программистов больше не было.
Айтиль — для ИТ, которое не пишет программы
Вот откуда слово «сервис» в ИТСМ (ИТ-сервис-менеджмент) — ИТ-подразделения прекратили писать программы и стали предоставлять услуги.
Вот что имеют в виду, когда говорят о «революции в ИТ, ответом на которую стал Айтиль и ИТСМ» — массовую замену программистов на администраторов и операторов поддержки.
Вот почему написали Айтиль — ни методы управления проектами, ни методы разработки ПО не годились в качестве инструкций «как жить» ИТ-подразделениям, основной продукцией которых вместо программ стали услуги.
Три дня боролся с программой rtorrent — начинает качать быстро, но через 4 минуты скорость падает со 11 500 до 200 килобайт в секунду. Чего только не делал: удалял и переустанавливал, ставил новейшую версию, менял настройки и самой программы, и компьютера, и роутера. Ничего не помогало. Конечно, я ни в настройках, ни в сетях особо не разбираюсь, поэтому все советы, которые я пробовал применить, были нагуглены. И что странно, в точности такая ситуация, как у меня, ни разу не попалась. Похожие — да, но другие, что на русском языке, что на английском. Решение я в конце концов нашёл, и в самом обидном месте: в разделе «Известные ошибки» на странице программы rtorrent. Текст дальше для тех, кто столкнётся с такой ситуацией, как у меня.
Симптомы: rtorrent 0.9.6 / 0.13.6 начинает скачивать на максимальной скорости, но после нескольких (у меня примерно после 4) минут работы скорость падает до 200 КБ/сек, и сам rtorrent начинает очень медленно реагировать на команды. Перезапуск rtorrent не помогает, перезагрузка компьютера помогает, но на те же 4 минуты.
Решение: я сохранял скачиваемое на NTFS-раздел, а в первой строчке в списке известных ошибок написано: rtorrent has issues with ntfs partitions. Когда я перенацелил параметр directory на ext4-раздел, проблема была немедленно и полностью решена.
Problem: rtorrent 0.9.6 / 0.13.6 starts at full speed, but after several (about 4) minutes the speed drops to 200 KB/s or even less. Aslo rtorrent became vary unresponsive to keys pressed. Restarting rtorrent doesn't help. Restarting the computer does, but only for another 4 minutes.
Solution: if you're saving the files to an NTFS partition, please be informed, that rtorrent has issues with NTFS partitions. Point 'directory' parameter to an ext4 partition, and the problem will be solved immediately.
Грустная часть: починив качалку, я вознамерился что-нибудь наконец скачать, но понял, что ничего не хочу.
Внимание! Если вы смотрели «Светофор» из IE11 или IE10 до даты этой заметки, то у вас не работали движки настройки. И картинка была вот такая, статическая:
А там три движка, и каждый картинку меняет. Первый управляет требуемым значением параметра, это меняет только раскраску. Остальные определеяют диапазон значений в ячейках (случайные числа, равномерное распределение), их изменение переделывает всю таблицу.
Сначала я два года ленился узнать, кто такой HR бизнес-партнёр, потом полгода я ленился написать эту статью. Но одно событие взволновало меня, и вот пишу.
Обычные кадровики
Жили-были кадровики, работали в отделах кадров, занимались своими кадровыми делами: искали кандидатов на вакансии, вели кадровое делопроизводство, выдавали трудовые книжки сотрудникам, которые «решили отправиться исследовать новые возможности», — нормально трудились.
«А. решил отправиться исследовать новые возможности», — так в компании N сообщили об увольнении одного из руководителей.
Примем во внимание, что и поиск кандидатов, и приём на работу, и увольнение — всё это стандартные запросы, т.е. на вопрос, был ли у кадровиков каталог услуг, ответ строго утвердительный.
Вспомним, что параметры некоторых из кадровых услуг не просто существуют, но ещё и контролируются государством, значит и контроль исполнения SLA налицо. Вывод: можем говорить о наличии процесса управления уровнем услуг.
Управление конфигурациями? Учёт сотрудников такой, что не всякая CMDB сравнится по количеству атрибутов и точности информации.
А что такое испытательный срок, как не время от внедрения изменения до его оценки (PIR)? Значит, и управление изменениями тоже было.
К чему клоню: задолго до того, как ИТ-службы узнали про Айтиль, кадровые службы уже работали по-айтилевски.
Великий кадровик
Однажды некий кадровик задумался, а правильно ли кадровики живут. Не лучше ли будет, если вместо выполнения входящих запросов в точности в том виде, в каком они пришли, кадровики будут исполнять их так, как лучше для бизнеса.
Например, просят айтишники нанять ещё 10 человек на 1-ю линию, потому что инциденты в срок не успевают решать, а кадровик, думающий о том, как лучше для бизнеса, им говорит: «У вас слишком много инцидентов. Надо не первую линию раздувать, а процесс управления проблемами налаживать. Поэтому вместо 10 человек на 1-ю линию я вам найду, троих, а ещё двоих найду таких, которые сделают так, чтобы инцидентов меньше стало. Само собой разумеется, что все вопросы, связанные с изменением внутренних процессов, процедур и оргструктуры, я, конечно же, решу сам. Ведь я же не просто кадровик, я думаю об интересах бизнеса.»
Когда кадровик так думает и делает, из обычного кадровика он превращается в HR бизнес-партнёра.
IT бизнес-партнёр
Аналогию и последствия для сотрудников ИТ-подразделений вы уже поняли: думай об интересах бизнеса, и ты уже не просто айтишник, ты — IT бизнес-партнёр.
Несмотря на то, что поиск по словам «IT бизнес-партнёр» выдаёт несколько ссылок, а на «Хэд-хантере» уже есть вакансии на такую должность, очевидно (особенно, если сравнить те две вакансии с «Хэд-хантера» друг с другом), что никакого общепринятого значения у термина «IT бизнес-партнёр» ещё не сложилось. Сформулируем, как должно быть.
IT бизнес-партнёр — классный термин. Он показывает, к чему надо стремиться: помни о потребностях бизнеса, стремись принести бизнесу пользу. Да, в Айтиле написано про выявление и удовлетворение потребностей бизнеса, но 90 % ИТСМ-проектов все ещё начинаются с управления инцидентами, а не со стратегии или каталога услуг.
Нельзя называть должность «IT бизнес-партнёр». Это самое плохое, что можно сделать с этим понятием. Если такой должности не будет, то каждый сотрудник ИТ-подразделения сможет быть IT бизнес-партнёром, то есть помнить об интересах бизнеса. Но если назвать должность «IT бизнес-партнёр», то сотрудники всех остальных должностей получат индульгенцию об интересах бизнеса не думать — ведь есть специально нанятые для этого люди. А специально нанятых людей будет очень мало. Проверим по «Хэд-хантеру»: «Сбертех» искал ровно столько же «партнёров», сколько искал X5 — одного.
Лучше писать «IT бизнес-партнёр», чем «ИТ бизнес-партнёр», потому что уже принято писать «HR бизнес-партнёр». Однообразие удобно.
Пусть «IT бизнес-партнёр» станет наградой, которую бизнес присуждает ИТ-сотруднику. Совершенно нормально, если эту награду смогут получить все сотрудники ИТ, это не приз в соревновании, когда первое место может занять только один. Наоброт, это что-то вроде аттестата зрелости, без которого на работу вообще не берут.
Многие слышали, что товары материальны, а сервисы нематериальны. Также есть люди, которые считают, что чего не видно, того и нет. Два похожих (они могли бы быть физически полностью одинаковыми, от этого ничего не поменялось бы) тонометра отличаются тем, что один из них мне принадлежит, а второй мне дали попользоваться в рамках программы дистанционного мониторинга здоровья. Т.е. один тонометр — товар, а второй — услуга.
Точнее, «как услуга». Именно так принято называть ситуацию, когда чем-то дают попользоваться. Тонометр по-английски называется Sphygmomanometer, поэтому аббревиатура для Sphygmomanometer as a Service будет SaaS, точно такая же, как для Software as a Service, хе-хе.
И вот, зная на 100 %, что один тонометров на самом деле SaaS, вы, тем не менее, не имеете никакой возможности определить, который из них какой. Потому что услуги невидимы.
При чём здесь ITIL?
Разницу между двумя тонометерами легко понять, если посмотреть, кто ими владеет и кто пользуется. Там, где владелец и пользователь одно лицо, у нас товар. Там, где владелец и пользователь разные, у нас услуга. И так всегда и везде, где для предоставления услуги нужны какие-то материальные объекты: аренда машин, помещений, перевозки и т.п.
И с ИТ-системами точно так же. Когда у ИТ-системы один и тот же владелец и пользователь, эта ИТ-система — товар. Когда у ИТ-системы владелец и пользователь разные, тут где-то рядом обязательно есть услуга, а может быть и не одна.
Переделал и вернул на сайт калькулятор доступности.
На курсах слушатели, люди с заметным опытом работы в ИТ, обычно удивляются, когда видят, что «4 девятки» — это всего лишь несколько минут допустимого простоя, за которые «мы же ничего не успеем сделать!»
Калькулятор покажет, например, сколько точно минут и секунд допустимого простоя у вас есть, если клиент требует X % доступности.
