RTzRa's hive - sysadmin

В помощь админу

anonymous@undisclosed.example.com (Anonymous) — Tue, 09 May 2017 15:34:00 +0000

В помощь админу

Список активных исходящих соединений на порты 80,443,25

# lsof -nP -i :80,443,25 +c 15

Узнаем дату и время запуска процессов

# ps -eo pid,lstart,cmd

Софт

Управление сетевой инфраструктурой - http://redmine.nocproject.org/wiki/noc/ЧтоТакоеNOC

Драйвер extN для Windows

anonymous@undisclosed.example.com (Anonymous) — Tue, 09 May 2017 15:34:00 +0000

Драйвер extN для Windows

ext, драйвер, windows, файловая система

ЛЕВ МЫШКИН - Уйти или остаться? Закулисные проблемы ...

anonymous@undisclosed.example.com (Anonymous) — Tue, 09 May 2017 15:34:00 +0000

ЛЕВ МЫШКИН - Уйти или остаться? Закулисные проблемы сисадминов

Что знает общество о жизни системных администраторов? Совсем немного. Попробуем приоткрыть завесу над проблемами рядового админа

Как говорит китайская пословица: «Кто предупрежден, тот вооружен». Знать о проблеме, говорить о ней, искать пути решения и единомышленников – вот какие цели преследует данная статья.

Это не «нытье»! Зачастую служащие считают, что если публикация посвящена негативным явлениям и их изучению, то автор – неудачник, который «ноет о своих проблемах». Меня всегда забавляла данная позиция. Получается, что если я читаю статью о причинах падения рубля, то автоматически должен считать, что автор – неудачник, обиженный на мировую финансовую систему. Но если некоторые общественные явления имеют место быть, то они возникли не благодаря «нытью неудачников», а по объективным причинам. Вот о таких явлениях и причинах пойдет речь. Герой нашего рассказа – обычный системный администратор обычной российской компании.

Как работает сисадмин?

Двойной рабочий день. Большинство офисов компаний и организаций работает в дневное время. График строго определен и не подлежит изменениям. И естественно, все сотрудники, включая системного администратора, обязаны соблюдать трудовой распорядок. Большинство компаний имеют систему учета рабочего времени – неважно, что это: автоматическая система контроля доступа по прокси-картам, журнал прихода-ухода или просто нужно вовремя показаться на глаза начальству.

Поэтому наш системный администратор приходит к началу рабочего дня и напряженно трудится на протяжении всего рабочего времени офиса.

Но вот рабочий день закончен – тут начинается самое интересное. Сотрудники уходят по домам, а наш системный администратор – нет… Многие из своих специализированных задач он может решить только в нерабочее время. Оно и понятно, нельзя мешать работе пользователей и компании в целом. Большинство профилактических и ремонтных работ так или иначе связано с остановкой служб и сервисов. Да и ввод в эксплуатацию нового оборудования или программного обеспечения подчас связан с необходимостью прервать обычное функционирование инфраструктуры. Вот и получается своего рода «вторая смена». Неоплачиваемая, конечно.

Руководство большинства компаний, как правило, не идет ни на какие уступки. Существуют, конечно, приятные исключения, когда для ИТ-персонала вводится гибкий график, оплачиваются переработки, добавляются дополнительные дни к отпуску… Но такие счастливые примеры – большая редкость на фоне общего равнодушия. Лично мне запомнилась замечательная фраза одного «босса», брошенная в ответ на просьбу хоть как-то решить вопрос с таким вот «двойным» рабочим днем: «Тебя никто не заставлял становиться системным администратором! Ты сам выбрал свою профессию». Как говорится, без комментариев.

Масла в огонь подливают и трудоголики. Казалось бы, в обычном офисе, где не требуется функционирование системы 24 часа в сутки и 7 дней в неделю, после 19.00 делай что хочешь – но не тут-то было! Некоторые сотрудники считают за правило задержаться на работе после окончания трудового дня. Трудоголики бывают настоящие и показушные.

Первые действительно любят свою работу и всей душой болеют за компанию. Их хоть и трудно, но все же можно по-хорошему уговорить прервать «кипучую деятельность на благо фирмы», чтобы дать возможность сисадмину решить свои задачи.

Другое дело – трудоголики показушные, которые используют сам факт проведения технических работ, чтобы лишний раз продемонстрировать свое рвение и лояльность начальству. Они если и закончат работу, то только со скандалом и утром обязательно демонстративно пожалуются на «безответственного компьютерщика», якобы не давшего вовремя завершить начатую работу.

В итоге приходим в 9.00, ждем до 21.00 ухода последнего трудоголика, а сами уходим в 23.00, а то и бежим, чтобы успеть до часу ночи, пока не закрыли ближайшее метро. А утром… утром снова к 9.00 на работу! Знакомая картина?

Виртуальный отпуск – это совсем просто. Как и положено большинству сотрудников, системный администратор имеет право на ежегодный оплачиваемый отпуск. Но когда приходит пора его использовать, наш системный администратор видит суровое лицо своего начальника и слышит до боли знакомую фразу: «Ну, ты же будешь недалеко от компьютера, доступен по мобильному, правда?» И все.

Забудьте про восхождение на горные вершины, байдарочные походы, романтический медовый месяц, когда «и пусть весь мир подождет»… Это все не для вас. Ваш удел – провести отпуск в «шаговой доступности» от компьютера, ожидая звонка с работы. Даже если у вас идеально отлаженная инфраструктура и сбои происходят реже, чем раз в полгода, все равно. «А вдруг что случится, а тебя нет?»

Я знаю системных администраторов, которые принципиально не берут отпуск, предпочитая получить денежную компенсацию, или, на худой конец, идут в отпуск и устраиваются на шабашку. Как объяснил мне один коллега: «Все равно нормально отдохнуть не дадут, так хоть деньги будут». Вот такой он, виртуальный отпуск.

Зачем он нужен, если все работает?

Допустим, наш системный администратор работал по 12-15 часов в сутки, перевернул горы документации и в итоге добился более-менее бесперебойной работы инфраструктуры. Компьютеры не виснут, сервера не перезагружаются, почта доходит до адресата, трафик не превышен… Красота. Живи да радуйся. Время сделать передышку, дописать документацию, провести работу над ошибками из Event Log (или System log – у кого как…). Но часто, очень часто системного администратора вместо заслуженной похвалы (я уже молчу о премии) ждет вызов к менеджеру по персоналу или руководству компании с предложением… уволиться по собственному желанию.

Все – прямо как в притче о коте, который за одну ночь переловил всех мышей, а поутру был выброшен на помойку. Но, в отличие от несчастного кота, сисадмин не может «не ловить мышей». Попробуйте остановить, к примеру, сервер с базами данных для бухгалтерии. Вот крику-то будет!

На деле все просто: «Если есть проблемы с компьютерами – значит, системный администратор плохо работает. Если проблем нет – системный администратор не нужен».

Конечно, первый раз подобный поворот судьбы воспринимается очень болезненно. Мне приходилось общаться с очень хорошими специалистами, впавшими в депрессию после подобного инцидента. Потом, после второго-третьего раза привыкаешь, появляется некий цинизм. Как там у Ильфа и Петрова в «Золотом теленке»: «Я потерял веру в человечество».

Как вы понимаете, работа по созданию бесперебойной инфраструктуры до конца не была доведена. Не дописана документация, не устранены полностью все ошибки… Это останется в качестве сюрприза для нового специалиста, которого возьмут на работу, когда ИТ-структура начнет давать трещину. Чаще всего сокращают самых высокооплачиваемых, а значит, и самых грамотных сотрудников ИТ-подразделений, хотя бывает и наоборот: оставляют одного или нескольких «профи», на которых навешивают всю оставшуюся работу.

За себя и за того парня

Еще одна особенность работы системного администратора заключается в том, что остальные сотрудники компании свято уверены в том, что он должен досконально знать все нюансы их трудовой деятельности и, главное, выполнять за них их работу. Такова человеческая натура: «Если сотрудник другого подразделения допускает ошибку – это сбой в компьютере и виноваты компьютерщики. Если несмотря ни на что работа выполнена – это исключительная заслуга именно его, менеджера, а системный администратор или даже весь ИТ-отдел вместе с франчайзерами и интеграторами все это время били баклуши и мешали работать».

И отказать этому «умнику» нельзя – такой скандал поднимется! Вот и сидит наш сисадмин поздними вечерами, перепроводит ошибочные бухгалтерские проводки в «1С», ретуширует фотографии для рекламного отдела, отсылает письма с первоначально неправильно вбитыми адресами.

Многие опытные системные администраторы в таких случаях говорят: «Как себя поставишь, так и будут относиться!» – и это верно. Однако сотрудники других подразделений, как правило, не должны что-то кому-то доказывать, постоянно отбиваясь от абсолютно несвойственной им работы. Вы представляете себе менеджера по рекламе, формирующего вместо бухгалтера отчет в «1С»? Или бухгалтера, верстающего макет новой презентации для отдела продаж? Вот и я не представляю. А сисадминам зачастую приходится делать и то и другое. Бывают, конечно, редкие исключения, когда ИТ-отдел работает исключительно по системе заявок, когда сотрудникам ИТ-подразделений запрещено касаться работы пользователей. В основном это крупные столичные компании с четким разделением труда и поминутным учетом рабочего времени. В большинстве же российских фирм и фирмочек царит обычный закон джунглей: «кто сильнее, тот и прав». И сисадмин там – не в числе «сильных».

Зиц-председатель Фунт и его последователи

Все вышеописанные проблемы – ничто по сравниванию с постоянным риском быть привлеченным к уголовной ответственности. Помните зиц-председателя Фунта из романа Ильфа и Петрова «Золотой теленок»? В его роли сейчас выступают системные администраторы большинства российских компаний. Наверное, уже не осталось обывателя, не слышавшего о пресловутом «деле Поносова» и преследовании организаций и физических лиц за пиратское программное обеспечение, или, как его еще называют, «нелицензионку» (Уголовный кодекс Российской Федерации, Статья 146. Нарушение авторских и смежных прав).

Но предприниматели отнюдь не спешат занять место в очереди за лицензионным софтом. Почему? Причина простая: за все нарушения будет отвечать системный администратор. Если будут выявлены нарушения, генеральный директор, главный бухгалтер, юрисконсульт и все другие сотрудники компании покажут пальцем на системного администратора и скажут что-то наподобие: «Мы здесь ни при чем, это он все понаставил. Мы ведь люди, от компьютеров далекие, ничего в них не понимаем». И наплевать, что системный администратор много раз предупреждал, просил, умолял – и устно, и письменно – купить лицензии на используемое в компании программное обеспечение или хотя бы по возможности перейти на бесплатный софт. А зачем? При покупке лицензий придется тратить деньги. При переходе на бесплатное ПО – терпеть неудобства. И не дай бог, при этом придется изучать что-то новое! Куда проще заклевать системного администратора – все равно судить будут его.

А ответственность в случае поимки отнюдь не маленькая. Самый минимум, который грозит системному администратору в этом случае, – условный срок и необходимость выплатить материальный ущерб, исчисляемый сотнями тысяч, а то и миллионами рублей. Работодатель при этом отделается предупреждением и торжественным обещанием купить лицензионное ПО.

При устройстве на работу вас, конечно, будут клятвенно заверять, что у компании наикрутейшая служба безопасности со связями в руководстве МВД, ФСБ, ЦРУ, Моссад и т.д. Что у «главного» в друзьях все российское и мировое правительство. Что у компании самые крутые юристы… Но на деле все не так.

В российских компаниях практически нет грамотных юристов, способных выиграть дело в случае нападок на нелицензионное ПО. А вот юрисконсультов, требующих от сисадмина поставить ему на компьютер взломанную версию «Консультант+», – пруд пруди.

Но и это еще не все. Во многих организациях системного администратора рассматривают не просто как установщика, а как «добытчика» этого самого нелицензионного ПО. Как часто наши сисадмины слышат фразы: «Что значит – не поддерживает новый формат? Что значит – нет дистрибутива? Ты еще не скачал с торрентов новую «крякнутую» версию?!!» А если в Интернете нужной программы не нашлось или нет возможности скачать, системный администратор в большинстве случаев пойдет на радиорынок и купит пиратский диск за свои деньги. Фактически сам за свои деньги покупает улики против себя. Мало кому приходит в голову мысль уговорить главбуха списать что-либо задним числом, рискуя быть пойманным. А с офисными любителями «вареза» системные администраторы воюют из года в год, и все безуспешно. Если же сисадмин все-таки проявит требуемую жесткость характера и скажет твердое «нет», то начальство быстренько подыщет «более адекватного и стрессоустойчивого сотрудника, готового иногда идти на компромиссы».

Не секрет, что российский бизнес зачастую не в ладах с законом. С налоговыми органами – почти всегда. Редко когда у компании все чисто в плане соблюдения норм и законодательных актов. А на системного администратора (при отсутствии специального подразделения по защите информации) возлагается ответственность по охране информации не только от злоумышленников, но и… от сотрудников правоохранительных органов. То есть, по сути, сисадмин должен вовремя прикрыть бизнесмена, нарушающего закон ради собственного обогащения.

На какие только чудеса не идут российские системные администраторы: тайными тропами выносят из офиса винчестеры с «черной бухгалтерией», прячут компьютеры (обычно это десктопы в роли серверов) в подвале или под фальшпотолком, шифруют данные всевозможными программами шифрования, зачастую не разрешенными для использования на территории РФ.

Если же системного администратора поймают за этими делами, если он будет упорствовать во время следствия, ему может быть предъявлено обвинение по следующим статьям Уголовного кодекса РФ:

Статья 294. Воспрепятствование осуществлению правосудия и производству предварительного расследования.

Статья 308. Отказ свидетеля или потерпевшего от дачи показаний.

Статья 316. Укрывательство преступлений.

Самое удивительное, что большинство сисадминов рискуют своей свободой, прикрывая бизнесмена от правоохранительных органов, за самый заурядный оклад. Никакой дополнительной платы за риск и подчас никакой благодарности системный администратор обычно не получает. Зато может получить нагоняй и даже лишиться части «серого» оклада за «несвоевременную реакцию».

Что такое получить условный срок или просто иметь в своей биографии пункт: «находился под следствием»? Это значит, что придется навсегда распрощаться с самой возможностью получить хоть какую-то более-менее приличную работу. Большинство российских компаний никогда не возьмут на работу человека, имеющего судимость. Потому что это «пятно на репутации компании». Девушки из отдела кадров будут мило вам улыбаться и говорить что-то наподобие: «Мы примем решение и вам перезвоним…». И никогда не перезвонят.

Максимум, на что вы сможете претендовать, – это на рабочую должность на каком-нибудь захудалом заводике, откуда все остальные бегут, как от лесного пожара. Помимо проблем с трудоустройством у вас будут и другие проблемы – например, с получением заграничных виз или с оформлением кредита… Фактически вы превращаетесь в «человека второго сорта». Может быть, имеет смысл уже сейчас задуматься о смене профессии, пока профессия не изменила вас?

Что у нас новенького?

«Самая близкая к системному администрированию профессия – микробиолог. У них, как и у нас, постоянно что-то выводится». Эту бородатую шутку я вспоминаю каждый раз, когда встает вопрос о том, чем профессия системного администратора принципиально отличается от многих других.

Во-первых, системный администратор, прежде чем приступить собственно к администрированию сети, должен получить солидный багаж знаний. Причем знания эти абстрактные, то есть в обычной жизни неприменимые. Например, знание стека протоколов TCP/IP необходимо только ИТ-специалистам, и больше никому. Почерпнуть их можно только из технической литературы, больше неоткуда. Попросту говоря, сисадмин должен прочесть большую кучу книжек.

Во-вторых, компьютерная область никогда не стоит на месте. Сегодня расслабился, не уследил за новостями – завтра вас обогнали коллеги, а послезавтра вы уже сидите на обочине прогресса и думаете, как это получилось оказаться в такой «дыре». Помимо технического прогресса постоянно возникают разного рода обстоятельства, которые нельзя проигнорировать, – например, появление новых вирусов, поиск уязвимостей, изменения в законодательстве. Не забываем про двойной рабочий день, и становится ясно, в каком цейтноте живет обычный системный администратор.

Что же касается методов получения информации, то здесь особых улучшений не предвидится. Все то же чтение документации и практический опыт, зачастую приобретаемый самостоятельно во время домашних экспериментов после основного рабочего дня.

И наконец, курсы повышения квалификации. Это самая больная тема. Если, к примеру, курсы по продуктам Microsoft системный администратор чисто теоретически еще может оплатить самостоятельно, то по редким технологиям, таким как, например, продукты компании Citrix Systems, обучение стоит баснословных для системного администратора сумм. Работодатель же отнюдь не спешит обучать свой персонал за счет компании. А если кого-то из специалистов и посылают на курсы, то, как правило, это преподносится как великое благодеяние: сотруднику ИТ-отдела постоянно напоминают, что теперь он должен отработать свое обучение, с ним предварительно заключается контракт, по которому он обязуется отработать длительный срок в компании (без повышения оклада, естественно) или вернуть сумму, выплаченную за его обучение. И никому не приходит в голову, что учиться – это тоже труд, и довольно тяжелый. Что новые знания нужны в первую очередь работодателю, и вполне возможна ситуация, что техническому специалисту эти знания нигде больше не пригодятся.

Утешает в данной ситуации тот факт, что системных администраторов настолько редко посылают на учебу, что это можно всерьез даже не обсуждать. Приходится корпеть над книгами или на ходу постигать принципы работы той или иной технологии.

Еще одно специфическое требование, предъявляемое к системным администраторам, – это знание английского языка. Суметь перевести технический текст, вести переписку с зарубежными коллегами. Разговорная речь требуется, как правило, реже, однако зачастую приходится общаться по телефону и даже лично с иностранными собеседниками. К большинству других профессий такие требования не предъявляются, а если и предъявляются, то неплохо оплачиваются. Например, если требуется бухгалтер или юрист со знанием английского, нанять такого специалиста стоит дороже. А вот для системных администраторов английский язык – дело само собой разумеющееся. Мало того, в большинстве российских компаний системный администратор – едва ли не единственный специалист, способный объясниться по-английски. (И не только по-английски. Иногда приходится знать и другие языки, например, немецкий, если используется оборудование Siemens). Вот и носят сисадмину тексты как к штатному переводчику: от курсовиков по «инглишу» до проектов договоров с иностранными партнерами. В качестве бесплатной нагрузки, конечно.

Сколько стоит быть сисадмином?

Быть сисадмином стоит недешево. Во-первых, системный администратор, как уже говорилось выше, обязан постоянно читать специальную литературу, чтобы поддерживать свой профессиональный уровень. Средненькая книжица на московских прилавках потянет примерно на 500 рублей. Толстые «гроссбухи» по специализированным продуктам и технологиям, таким как Cisco или Oracle, могут стоить и 1000, и 1500 рублей. А подобных книжиц хороший системный администратор прочитывает за год минимум пять-шесть штук.

Во-вторых, системный администратор обязан иметь компьютер весьма неплохой конфигурации. Многие сисадмины имеют дома экспериментальные сети или виртуальные платформы (считай, мощный компьютер) для тестирования и обкатки решений. Делается это не из любопытства, а из стремления хоть как-то сократить вынужденные неоплачиваемые переработки, сведя к минимуму сбои оборудования и программного обеспечения. Оттестированное в домашних условиях решение имеет больше шансов на жизнь, нежели внедряемое «по ходу пьесы». И конечно, необходимо попробовать на практике то, что было прочитано в умных книжках.

В третьих, системный администратор обязан иметь дома постоянно работающее подключение к Интернету на неплохой скорости (допустим, 1-2 Мб/с). В последнее время это становится обычным требованием работодателя.

Почти всегда за все это системный администратор платит из своей и без того небольшой зарплаты. Работодатели в большинстве своем отказываются компенсировать даже самые большие затраты на литературу. Про затраты на Интернет и домашний компьютер лучше вообще умолчать. Максимум, на что здесь может рассчитывать системный администратор, – на старенький, давно списанный компьютер, подаренный широким жестом с барского плеча: «Бери уж, так и быть, все равно выбрасывать…»

Да, бывают исключения. Когда сисадмину компенсируют расходы на мобильный, выделяют корпоративный ноутбук и не только покупают техническую литературу, но и оплачивают специализированные курсы. (А ведь как часто все это входит в стандартный «корпоративный пакет» для сотрудников других подразделений – например, менеджера по привлечению клиентов!) Но такие случаи можно пересчитать по пальцам.

О бонусе редком замолвите слово

Традиционная система «кнута и пряника» к системному администратору применяется только «кнутом». Российский бизнесмен не понимает, за что можно премировать системного администратора. «За то, что не было сбоев? Так значит, он и не работал вовсе. Если нет аварий – то и чинить нечего. За то, что были сбои и он их оперативно устранил? Так сам виноват, что допустил подобную ситуацию».

Зато всегда есть за что наказать. За то, что не предусмотрел, не предотвратил, не предупредил, резко разговаривал с пользователем, отказался ставить нелицензионный софт – да мало ли за что! В итоге получается, что даже свои куцые оклады системные администраторы получают с вычетом всевозможных «штрафов» (которые, кстати, запрещены Трудовым кодексом РФ).

А вот с бонусами и всяческими премиями все просто. Менеджеры по продажам регулярно получают премии и проценты с продаж, неплохо обстоят дела и у отдела поставки, и у бухгалтерии. А системный администратор, который, собственно, и организовал техническое обеспечение всех этих продаж, поставок, отчетов, премию не получает. В представлении типичного российского бизнесмена ИТ – это «пылесос для денег». Вспоминаю замечательную фразу, сказанную одним из «боссов»: «А за что вам премию платить? Вы и так только тратите. Вон недавно сервер вам купили, вы еще полгода его отрабатывать должны». Правда, у системного администратора есть небольшая возможность «пошантажировать» начальство увольнением и попросить прибавку к зарплате. Потому что искать нового системного администратора – дело непростое и почти всегда неблагодарное.

Конечно, бывают организации, работающие по правилам – например, внедрившие ITIL, где сисадмины получают премию за соблюдение SLA. Еще помню одну фирму, где руководство по итогам успешного года просто повысило зарплату на 10% всем сотрудникам, в том числе и ИТ-отделу. Но таких компаний – единицы.

Возраст, или есть ли жизнь после сорока?

Как часто читаешь в тексте вакансии: «…требования: мужчина, до 40 лет…» Или даже: «…до 35 лет» Почему? Я часто спрашивал об этом менеджеров по персоналу и представителей руководства различных компаний. Были самые разные ответы. Например: «После 35 человек уже не энергичен». Или: «После 30 лет уже трудно усваивать информацию».

Все эти доводы лично мне кажутся очень сомнительными. Люди настолько разные, что пытаться причесать всех под одну гребенку просто не имеет смысла. Наиболее точным ответом был следующий: «Человеком после 30 лет трудней управлять». Это правда. Зрелого мужчину труднее обмануть, подставить, прогнуть по зарплате. На него не наорешь. Ему труднее промыть мозги, что он – обслуживающий персонал и всем обязан своим существованием [1]. Что же делать системному администратору после 40 лет?

Вариантов масса: стать начальником, уйти в дворники или в программисты, открыть свой бизнес… Тогда от «сисадминства» придется отойти. Получается, что системный администратор – это временная профессия. Что-то вроде «Макдональдса» для инженеров.

Для сравнения: главный бухгалтер, юрист или финансовый аналитик средних лет ни у кого не вызывает вопросов. А вот системных администраторов старше 40 лет с точки зрения российского бизнеса быть не должно.

Сисадминская карьера

Как известно, системный администратор не может стать генеральным директором компании, в которой работает. Менеджер по продажам – может. Сотрудник финансового отдела или отдела поставки – может. А сисадмин – нет. Карьерный «потолок» – начальник ИТ-отдела. Если специалисту хочется большего, ему все дружно советуют перейти работать в системный интегратор или ISP. Это довольно спорный вопрос.

Во-первых, рынок системной интеграции в России находится в зачаточном состоянии. Зачем платить большие деньги за обслуживание у интегратора, если за мизерную сумму можно нанять офисного «раба», работающего по полторы-две смены? К тому же специалистов из СИ будет весьма проблематично привлечь к ответственности в случае возбуждения уголовного дела по факту использования контрафактного ПО или заставить нарушить закон, прикрывая заказчика. Гораздо проще в этом случае иметь дело с собственным системным администратором. Что же касается ISP, скажем проще: «Их на всех не хватает». Количество компаний-провайдеров невелико, уровень оплаты труда далеко не самый большой. На одну мало-мальски достойную должность сразу находятся десятки, а то и сотни претендентов. Поэтому возможности вертикального карьерного роста для системных администраторов весьма и весьма ограниченны.

В качестве альтернативы HR-служба часто предлагает так называемые «возможности горизонтального карьерного роста». Что это такое?

В идеальном варианте предлагается следующая схема: некий специалист параллельно начинает изучать смежную область, становится замечательным специалистом и либо окончательно переходит в эту область, либо за хорошую плату выполняет дополнительные функции. Хороший пример: системный администратор изучает аспект администрирования баз данных и становится DBA. На практике все гораздо проще. Уволили веб-программиста и функции по поддержке сайта «повесили» на сисадмина с доплатой в 15% от оклада. По сути, это «горизонтальная карьера» дворника, подметающего два участка почти за те же деньги. Сколько таких «горизонтальных карьер» за мизерную доплату и вовсе без нее было создано в кризис – просто уму непостижимо. Зачастую от системного администратора требуют знания программирования в «1С», умения «мастерить» веб-сайты, рисовать презентации, вести документооборот… Откроешь любой «работный» сайт и просто диву даешься: не профессия, а одна большая «горизонтальная карьера».

При написании первой части статьи я постарался обобщить и озвучить большую часть проблем, с которыми сталкиваются системные администраторы. Признаюсь, у меня самого отнюдь не радужное впечатление от обилия проблем и напастей, описанных в данном материале.

Во второй части будет проведен анализ причин, благодаря которым сложилась данная ситуация. В третьей части будут предложены пути выхода из нее и некоторые способы облегчения жизни системного администратора.

Приложение

Сколько стоит сисадмин?

На вопрос СА отвечают посетители форума журнала

Выше уровня квалификации не прыгнешь

Мой труд стоит ровно столько, сколько за него платят, т.к. мы живем в стране с рыночной экономикой. Если оплата занижена – следует уволиться. Достойной для себя зарплатой считаю среднюю по региону для данного уровня квалификации и стажа работы.

Если мы говорим об оплате труда сисадминов, то надо понимать, что это – обслуживающий персонал, в отличие от системных инженеров и ИТ-менеджеров. Другое дело, что зачастую системные администраторы выполняют две последние функции, даже не подозревая об этом.

Трудно придумать на этой планете работу проще и хуже. Компания Microsoft утверждает, что благодаря великолепнейшему графическому интерфейсу ее серверами может управлять дурак. Поэтому на работу сисадминами на графические интерфейсы набирают, как правило, самоучек. Понятно, что платить им много никто не будет.

Такая ситуация абсолютно одинаковая во всех странах. В книгах «Руководство администратора Linux», «UNIX. Руководство системного администратора. Для профессионалов» и прочих написано, что работа UNIX-администратора в США нудная, суетная, без выходных и сравнительно низкооплачиваемая. Занимаются такой работой в США пожилые люди (или молодые – как временной подработкой).

В российской компании сисадмин свободнее

Я работал и взаимодействовал с компаниями в электротехнической области. В них зарплаты стандартные для рыночного уровня (деревню не считаем). Сисадмины меняются, как сезонный ветер. Их там просто высасывают и выкидывают. Нет сисадмина в западной компании, который не хочет свалить в менеджмент. Но внешне все ОК! Где сисадмин свободнее в своих решениях, где он может внедрить что-то из того же Open Sourse? Безусловно, только в российской компании.

Платить могли бы и больше

У нас компания маленькая, потому и зарплата админа тоже не слишком высокая. Но зато начальство постоянно придумывает различные хитрые задачи, на которых можно очень хорошо набираться опыта. Соответствует ли зарплата квалификации? Это решает скорее HR и менеджмент. Хотя, думается мне, могла бы быть и больше. Переработки бывают очень редко, но если бывают, то работать приходится «до упора».

Закулисные проблемы сисадминов. Часть 2

Продолжаем дискуссию «Сколько стоит сисадмин?», начатую в №4 за 2010 г. В чем причина нелегкого админского житья-бытья? Всегда ли виноват сам человек или обстоятельства сложились против него?

В первой части [1] я постарался описать проблемы и опасности, которые подстерегают системного администратора в его работе: от двойного рабочего дня и виртуального отпуска до вполне реального тюремного заключения за использование по требованию работодателя нелицензионных продуктов. В этой статье речь пойдет о причинах данных явлений и путях их преодоления.

Почему все так печально?

1. Потому что это удобно. Подумайте сами, зачем тратить деньги, если всегда можно найти «чудика», работающего по полторы-две смены, имеющего зарплату, как у секретарши и готового в случае чего «получить срок» за нелицензионку вместо босса, пусть даже условно или с отсрочкой приговора. Если системные администраторы не в состоянии оценить по достоинству свой труд, свой риск, свое время, за них это делают шустрые российские бизнесмены.

2. Потому что наш бизнес не ориентирован на ИТ. Еще одна причина кроется в традиционных «особенностях» российского бизнеса. В первую очередь это нечестная конкуренция, основанная на коррупции и протекционизме. Зачем внедрять новую, более эффективную (и более дорогую) систему управленческого учета, которая повысит относительное конкурентное преимущество на 10 процентов, если можно просто дать взятку чиновнику и получить стопроцентную «фору» перед возможными и невозможными игроками на рынке? Зачем тратить немалые крупные суммы на лицензирование программного обеспечения или переходить на бесплатное ПО, если можно просто заплатить проверяющим? Не получится проверяющим – нанять юриста, чтобы отмазать топ-менеджмент и все свалить на админа. Все равно это дешевле, чем покупать все лицензии на используемое ПО.

Получается, что системному администратору просто нет места в этой «теневой игре». Отчеты в налоговую он не носит, от проверок не отмазывает (как, например, нужный человек в службе безопасности), госзаказы не проталкивает… С точки зрения типичного российского предпринимателя это просто нахлебник какой-то!

3. Потому что нет привычки анализировать риски. Еще одна особенность российского бизнеса – неумение и нежелание анализировать риски, считать убытки и утерянную выгоду. Если еще с подсчетом прямых убытков горе-аналитики как-то справляются, то в случае с утерянной выгодой это просто «темный лес и ни одной звезды». Как часто приходится становиться свидетелем подобного диалога в обычной московской компании, где 100-150 активных пользователей, плюс филиалы:

– Если мы не приобретем и вовремя не заменим жесткий диск, выйдет из строя контроллер домена.

– И что будет?

– Никто не сможет работать минимум три часа.

– А когда это случится?

– Учитывая, что оборудование выработало предельный срок службы, это может произойти в любой момент.

– Ну вот когда случится, тогда и купим…

Сколько стоит потерянный день, какие переговоры могут быть сорваны, какие сделки не заключены или отсрочены, сколько заработной платы будет выплачено зря… Да никому это не интересно подсчитывать, и учредителям в том числе! А вот лишние три-четыре тысячи рублей за жесткий диск – вполне наглядный «убыток».

В большинстве российских компаний просто некому учитывать подобные нюансы. Хорошие финансовые аналитики и стоят хорошо… в смысле – дорого. Обычному «офисному планктону» такие задачи не по зубам. Но даже если на стол генеральному директору или председателю совета директоров ляжет подробный анализ рисков для компании, связанных со сферой ИТ, да еще и составленный профессиональными экономистами, надеяться на то, что пресловутый жесткий диск все-таки будет куплен, еще рано. Всегда может сработать психология: «А вдруг не случится?» Это мы с вами про жесткий диск говорим.

Если же говорить о зарплате сисадмина, то слова о подсчете рисков в реалиях российского бизнеса звучат просто невероятно. А риски тем не менее существуют, и немалые. Вспоминается пожар в редакции некогда известного глянцевого журнала. Грустные люди бродили по пожарищу, выискивая внешне выглядевшие неповрежденными диски и куски распечаток в надежде выскрести из этого хоть какие-то остатки материала. Причина раскопок» банальна: экономили на должности системного администратора. Роль сисадмина играл «мальчик» из ближайшей службы сервиса, чьей квалификации едва хватало на то, чтобы переставить Windows. Имей они в штате (пусть даже на неполный рабочий день) или на аутсорсинге квалифицированного сисадмина, который знает, что такое резервное копирование off-site (вывод резервных копий за территорию на случай форс-мажорных ситуаций), все бы окончилось совсем иначе. Да что там резервное копирование! Зачастую кресло даже не в директорском, а в замдиректорском кабинете стоит дороже, чем все серверное оборудование компании.

Конечно, есть организации, где многое, очень многое зависит от труда рядовых «айтишников». Это в первую очередь трейдерские компании, банки, средства массовой информации, конструкторские бюро, рекламные агентства. Но и там на системного администратора смотрят как на некий необязательный инструмент, мол, «если припрет – обойдемся». Частично это происходит из-за недальновидности руководства и сотрудников, частично – плоды целенаправленной политики «разделяй и властвуй». И в любом случае в проигрыше оказывается сисадмин.

Может создаться впечатление, что в российском бизнесе информационные технологии не нужны и не востребованы. На самом деле это не так. И бухгалтерия, и реклама, и управленческий учет, и топ-менеджмент – все-все с удовольствием работают «на компьютерах», совершенно забывая поблагодарить тех, кто эти компьютеры заставляет работать как надо.

В то же время не стоит забывать, что после распада СССР новая Россия остается технически отсталой страной. Научно-технический прогресс определяется не количеством iPhon-ов у «офисного планктона», а развитием науки, высокотехнологичных отраслей народного хозяйства, системы образования. И традиционно в технически отсталых странах в почете не тот, кто обладает большим объемом технических знаний, а тот, кто может похитрее обмануть, посильнее запугать, подешевле купить и подороже продать. Было бы странно на фоне общего упадка научной и технической мысли требовать уважения к представителям технических профессий.

«...Мамы разные нужны, мамы всякие важны...»

На память приходит эпизод, когда сотрудница одной уважаемой компании, забыв дома пропуск, извинялась, вежливо просила охранника пропустить ее, смиренно благодарила его, а придя на рабочее место, орала благим матом на системного администратора, требуя, чтобы тот немедленно восстановил пароль для входа в систему, который она успела забыть за выходные. Замечательная фраза надолго врезалась в память: «А вы все тут для чего, если я должна еще и свои пароли запоминать?!!» Почему на охранника не кричала? Потому что тот хоть и маленький, но начальник, а сисадмин – «это же обслуживающий персонал!»

Самое интересное, что большинство системных администраторов действительно уверовали в то, что они – «обслуживающий персонал», что их основная задача – «обслуживать пользователей». Я не знаю, кто первый ввел в обиход подобное словосочетание применительно к сисадминам. Могу только сказать, что если это был человек, не имеющий отношения к Computer Science, это поистине гениальный ход. Гениален он в первую очередь тем, что легко позволяет недоплачивать за труд. Казалось бы, чего проще: убедить людей в том, что они «обслуживающий персонал», денег фирме якобы не приносят, поэтому и платить им можно меньше, чем другим.

Конечно, это глупость. В современных бизнес-процессах участники настолько плотно интегрированы между собой, что выделить, кто из них главнее, просто нереально. Попробуйте, например, удалить из офиса уборщицу. Компания на глазах начнет хиреть, слабеть, производительность труда будет снижаться, и в итоге ее легко обойдут конкуренты.

В России, конечно, ситуация немного иная, но все равно без уборщицы плохо. Даже деления на front office и back office на самом деле от лукавого. В современном менеджменте есть понятия «бизнес-процесс», «звенья» или «сегменты» бизнес-процесса, а вот «обслуживающего персонала» – нет.

Чтобы до конца развеять этот миф о системных администраторах, обратимся к определению «обслуживающего персонала». Кого мы в повседневной жизни называем обслуживающим персоналом? Горничных, официантов, швейцаров, парковщиков… Несмотря на кажущееся различие в профессиях, у них есть много общего.

Для освоения этих профессий не требуется высокой квалификации или редких способностей. Кто может стать официантом? Да любой, кого возьмут. В элитных отелях и ресторанах есть школы официантов, но таких заведений – единицы, и обучают в них, как правило, своих же сотрудников. Главное здесь – желание работать официантом и умение быть услужливым. Из этого требования к услужливости проистекает одна любопытная деталь, которую можно отнести ко второму признаку.

Обслуживающий персонал получает чаевые, по крайней мере, может на них рассчитывать. Попробуйте не оставить в кожаной книжечке меню лишнюю купюру – официантка вас смерит таким презрительным взглядом, что «лучше уж на свет не рождаться»… А что сисадмин? Да ничего, пашет по две смены, о сверхурочных не заикается, еще и диски да книжки за свои кровные покупает…

Третий отличительный признак – степень ответственности. Что произойдет с клиентом, если его плохо обслужит официантка? В худшем случае – уйдет домой голодным. Если системный администратор обвалит сеть и выведет из строя сервера – голодными (и надолго!) останутся не только все сотрудники компании, но и учредители, а также члены их семьей.

Системный администратор по определению не является обслуживающим персоналом. Это – ключевой специалист компании, на котором держится вся ее информационная структура.

Почему технарей считают простачками

Как правило, во многих компаниях, особенно в торговых, технарей немного. Работа большинства сотрудников лежит в экономических или гуманитарных сферах, попросту говоря – это работа с людьми. Они воздействуют на других людей с целью достижения цели, например: продать товар, заключить сделку, выпросить отсрочку платежа и так далее. Подобные воздействия можно назвать манипуляциями.

Манипулировать людьми можно по-разному. Кто-то любит лесть, а кто-то понимает только силу. Кто-то боится за завтрашний день, а кто-то не любит рутины… «Погладить по шерстке», нажаловаться начальству, устроить истерику в нужный момент – все это примеры манипуляций. Естественно, системный администратор, который пытается играть с подобной публикой по ее правилам, обречен все время оставаться в дураках. Технарями легко манипулировать, они, как правило, не распознают манипулятивные ходы, а если и распознают, то в самый последний момент, когда, как говорится, дело сделано. Возможно, отсюда и некоторое пренебрежение со стороны «офисного планктона» по отношению к ИТ-сотрудникам, как к неким простачкам, которые «сами ничего не могут». А у вечно задерганного сисадмина нет ни времени, ни сил на то, чтобы обращать внимание на все эти хитросплетения. Искусно раздутый миф о том, что системный администратор – это обслуживающий персонал, можно с полной уверенностью отнести к первоклассной манипуляции.

Много вас, братцы, стало...

Так сказал мне однажды директор филиала одной крупной российской компании в ответ на мой вопрос о причинах снижения зарплат в ИТ. В свое время, когда компьютеры были редкостью, люди, умеющие с ними работать, были редкостью еще большей. Но время шло, персональный компьютер из средства проектирования и производства вычислений превратился в игрушку, в канцелярский инструмент. Это вызвало приток на рынок труда специалистов новой формации, молодых ребят, умеющих хорошо поставить «виндовс». Любой студент, переустановивший на своем домашнем компьютере операционную систему, уже считает себя специалистом. Если же он видел через чье-то плечо внешний вид оболочки командной строки – например, bash – и «хакнул» под административными правами реестр на своей машине, введя парочку ключей, то считает себя просто суперспецом. И конечно же, наш герой изберет профессию системного администратора или, в крайнем случае, инженера техподдержки. Зачем еще чему-то учиться, что-то зубрить, где-то практиковаться… Вот она, готовая профессия! «Накатил винду», «вбил дрова», «воткнул офис с фотошопом»… Красота! Как сказал мне один молодой «компьютерный гений»: «Ну не в Макдональдс же идти!» Но и отношение работодателей к системным администраторам на российском рынке труда такое же, как к работникам известного фастфуда, и предлагаемая заработная плата примерно та же.

Помните, в детстве мы думали, что мороженщик ест сколь угодно мороженного, киномеханик в любой момент может смотреть кино, какое захочет. Примерно так сейчас молодые люди думают, что системный администратор играет на компьютере в новейшие компьютерные игры, когда захочет. И горько разочаровываются, когда узнают, что это не так. Но подобные детские иллюзии имеют свойство передаваться окружающим. В итоге они начинают думать, что системные администраторы на самом деле ничего не делают, только играют в компьютерные игры.

А между тем техника усложняется, появляются новые устройства и сервисы, возникают новые угрозы. В первой части этой статьи я писал про сходство с микробиологами, у которых «постоянно что-то новенькое выводится». Серьезным специалистам все труднее конкурировать с «молодняком», готовым работать за зарплату кассира в Макдональдсе. Становится крайне трудно доказать работодателю, в чем отличие профессионального ИТ-специалиста от «компьютерного гения», едва научившегося переустанавливать операционку, при том что оба написали одинаковые резюме. (Как правило, новички «пихают» в резюме все понятные и непонятные околокомпьютерные слова, которые когда-либо услышали.)

Но «старикам» еще не так плохо, у них есть что показать в резюме помимо названия служб и сервисов: опыт, рекомендации, сертификаты… Гораздо труднее приходится тем молодым людям, которые пришли в системное администрирование не как в Макдональдс, а обдуманно и всерьез выбрав себе эту специальность. И будь молодой инженер хоть сто пядей во лбу, сегодня он обречен быть одним из многих…

Помимо этого снижается общая планка заработной платы, не в лучшую сторону изменяются результаты всевозможных социологических и маркетинговых исследований (например, пресловутый «Индекс HeadHunter»). Некоторые представители «старой школы» еще тщетно надеются, что «рынок все расставит по местам», «чем больше халтурщиков, тем более востребованы профессионалы». Но это пустые надежды. Демпинг неотвратимо делает свое дело. Зарплатный «потолок» снижен, стереотипы сформированы. В итоге мы имеем то, что имеем.

Никто не обращает внимания на то, что информация – самая дорогая ценность компании, что компьютерная сеть в руках дилетанта страшнее гранаты в руках обезьяны. Если на стол менеджеру по персоналу лягут два похожих резюме, предпочтение будет отдано кандидату, претендующему на более низкую зарплату. Если такового не найдется, то просто одному из кандидатов предложат сумму гораздо меньше той, на которую он претендовал вначале. «Если не видно разницы, зачем платить больше?»

«Когда в товарищах согласья нет...»

«На лад их дело не пойдет». Так звучит мораль небезызвестной басни Крылова «Лебедь, рак и щука». Именно так обстоит дело и с системными администраторами. Давно канули в Лету времена, когда «компьютерщик был обязан помочь компьютерщику». Когда, придя на собеседование и узнав, что руководство компании таким образом хочет втихую «убрать» нынешнего сисадмина, соискатель разыскивал своего незадачливого коллегу и сообщал ему сей грустный факт. С приходом молодых «компьютерных гениев» все изменилось. Да и представители «старой школы» демонстрируют отнюдь не лучший пример для подражания.

Есть немало примеров того, как кто-нибудь из админов, устав от проблем и безденежья, создает на форуме ИТ-специалистов топик на тему «Ну почему все так плохо?». Что ему ответят «уважаемые коллеги»? Самые мягкие выражения, которые он прочитает в свой адрес: «Хватит ныть», «Ты неудачник», «Убей себя об стену» и т.п. Любая попытка привлечь к анализу нездоровой ситуации других «товарищей по профессии» воспринимается исключительно как проявление слабости, как нытье, нежелание учиться и работать.

Со стороны может создаться впечатление, что все проблемы, сваливающиеся на голову российского системного администратора, происходят исключительно оттого, что он глупый, ленивый, не умеет учиться, а кому надо, тот получает «ого-го как много» и проблемы решает на раз-два-три. На самом деле это не так. Все люди склонны преувеличивать уровень своих доходов и свои профессиональные успехи, некоторые – в разы, некоторые – в десятки раз. Поэтому верить в байки о том, что «у других все нормально, только у тебя все плохо», пожалуй, не стоит.

Забавно наблюдать, как даже те, кто готов прийти на помощь в случае технической проблемы, начинают радостно клевать неудачника, посмевшего пожаловаться на нелегкую жизнь своим «товарищам по оружию».

Что является причиной такого расслоения сисадминского общества? В первую очередь это неравные стартовые позиции. Кому-то на старте достались Oracle и SPARC, кому-то – «1С» и самосборные сервера. Кто-то изучал технологии Cisco на последних курсах вуза, кто-то – по книжкам, прочитывая по несколько страниц слипающимися глазами после пресловутого «двойного» рабочего дня [1].

Соответственно, сегодня профессиональные и материальные успехи могут сильно варьироваться в зависимости от стартовых условий сисиадмина. И конечно, товарищи, получившие вначале более выгодные условия, не откажутся потешить самолюбие и поклевать своих менее удачливых собратьев.

Второй причиной недружелюбия среди сисадминов по отношению друг к другу я бы все-таки назвал произошедшую смену поколений. Представителям «старой школы», перешагнувшим тридцатилетний рубеж, проблемы молодых специалистов кажутся несерьезными. Когда у вас есть неплохо оплачиваемая (по его мнению) работа, опыт, связи, страдания юного собрата на тему «Что делать, когда кидают по зарплате» кажутся смешными. Человек склонен забывать, что всего каких-то пять-семь лет назад он запросто мог оказаться в точно таком же положении. В то же время многим молодым специалистам представители старшего поколения порой кажутся высокомерными занудами, по любому вопросу отправляющими их читать документацию.

Третьей причиной можно назвать некое смещение приоритетов в среде ИТ-специалистов. В свое время, когда в ИТ попадали в большинстве своем умные интеллигентные люди, пресловутый «закон джунглей» попросту не принимался «компьютерной тусовкой». Интернета не было. «Своих» знали лично и всегда помогали друг другу.

С появлением Интернета и приходом в ИТ множества случайных людей среди сисадминов стали индивидуумы, не слишком обремененные совестью, культурой поведения и другими «несовременными» понятиями. Со временем старое сообщество компьютерщиков кануло в Лету, превратившись в сборище одиночек. Это только на руку не совсем чистоплотному российскому бизнесу, потому что дает возможность за счет разобщенности системных администраторов снизить зарплатный «потолок» и манипулировать профессионалами. Как говорится, «разделяй и властвуй».

Ну что ж, проблемы описаны, причины проанализированы. Остается понять, что нужно делать, чтобы выйти из тупика. Этому будет посвящена третья часть статьи.

Закулисные проблемы сисадминов. Часть 3

Мы завершаем дискуссию, посвященную типичным проблемам системного администратора и анализу их причин. Поговорим о том, что делать?

Я был молод и состарился, и не видал праведника оставленным и потомков его просящими хлеба…

«Псалмы». Псалом 36

Достаем из-под пыльного дивана свою гордость

Первое, что необходимо сделать, – научиться себя уважать. Твердо зарубите себе на носу: без самоуважения нет уважения окружающих. Забудьте о том, что вы – «обслуживающий персонал». Вы – ключевой специалист компании. И самое главное – вы здесь не отбываете наказание лишением свободы, а добровольно заключили трудовой договор, который можете расторгнуть в любой момент. Вы – не гастарбайтер на стройке и с голоду не умрете.

Не позволяйте на себя кричать и пренебрежительно обращаться. Забудьте об угрызениях совести: «Вот до чего довел человека». Помните: слезы, крик и истерика – это всего лишь один из методов манипуляции.

Хотя не существует универсального средства предотвращения конфликтов, есть известные методики их разрешения. Например, можно сказать: «Мы продолжим этот разговор позже, когда вы будете готовы к диалогу», – и спокойно выйти из кабинета (или повесить трубку телефона). Повторяю, все нужно делать именно ровно и спокойно, без дьявольской усмешки и или нервных выпадов. Не превращайте разговор в перепалку и не скатывайтесь до оскорблений. В особо серьезных случаях имеет смысл первому пожаловаться руководству компании на безобразное поведение пользователя. Это никакое не стукачество, а нормальные меры по установлению деловой атмосферы. В конце концов, вас приняли на работу для решения технических проблем, а не для упражнения в злословии отдельных индивидуумов.

Многие сисадмины жалуются на глупые шутки на тему «компьютерного гения», «хакеров», «ну что, опять все сломали» и т.д. Это тоже манипулятивный прием, что-то вроде попытки показаться «своим парнем» одновременно с демонстрацией своего превосходства. Достаточно просто устало посмотреть и сказать: «Извините, мне трудно оценить юмор, очень много работы. График плотный. Вы по делу или просто поговорить?» Уверяю, в 90% случаев подобный «шутник» постарается воздержаться от своего плоского юморка.

Основная ошибка, которую делают технические специалисты при защите своего достоинства: они начинают «перегибать палку». Ваш ответ, как однажды сказал наш премьер Владимир Путин, должен быть «адекватным, но асимметричным». Поконфликтовали, поставили пользователя на место, пожаловались начальству и… забыли о нем до следующего раза. Не надо устраивать вашим оппонентам «особый уровень безопасности», тянуть со сроками исполнения заявок и т.д. Помните: ваша задача – не «разобраться» с пользователем, а обеспечить себе минимум проблем при максимуме материального вознаграждения.

Инвестировать, реинвестировать, уходить

Рассмотрим, какие возможности нам предоставлены.

Возможность первая. Переквалифицироваться

Именно так звучит основная рекомендация на тему «что же делать, если бизнес перестал приносить ожидаемый доход». Идея рассматривать собственную профессию как бизнес, оценивать ее успешность по тому же принципу отнюдь не нова. Большинство консультантов по трудоустройству и коучингу так или иначе подводят своих клиентов к этому.

Что можно посоветовать системному администратору? Если подсчитать затраты на входе (трудозатраты в том числе) и денежный эквивалент на выходе, получается довольно печальная картина. В свете семейного бизнеса работа рядового системного администратора предстает явно убыточным предприятием. Возникает вопрос: что делать? Вот тут-то и пригодится данная рекомендация.

Первое, что мы делаем… инвестируем некоторые средства в свой разваливающийся бизнес, то есть в свою профессию. Следует отдавать себе отчет, что это должна быть последняя инвестиция, возможно, довольно крупная, но именно последняя. С ее помощью мы выжимаем остатки того, что может дать умирающий бизнес. Вам решать, что это будет: специализированные курсы, закупка литературы, обновление домашнего тестового компьютера, подарок шефу, чтобы получить повышение, или все вместе. Это нужно, чтобы повысить свои доходы и отложить накопленную разницу в денежном эквиваленте. Это ваш спецфонд для дальнейшего прорыва.

Пока деньги копятся, вам необходимо определиться со сменой профессии. Я не оговорился. Вселенная не исказилась, и вы действительно читаете эти слова на страницах журнала «Системный администратор». Просто ситуация такова, что если не любят, нормально не платят и еще норовят упечь в тюрьму, зачем далее испытывать судьбу? Чтобы лучше понять ситуацию, обратимся к истории.

Во времена трудных 90-х годов прошлого века, когда массово закрывались предприятия, людей выбрасывали на улицы, а оставшимся годами не платили зарплату, профессия программиста стала прибежищем для многих инженеров и просто умных людей, в одночасье ставших бесполезными в своей профессии. (В те времена люди, работавшие с вычислительной техникой, обязаны были уметь все: от ремонта с паяльником материнской платы до программирования отчетов для бухгалтерии.) Имея скромный выбор: «пойти торговать на базар», «пытаться прокормить свою семью с огорода» и «податься в программисты», – многие выбирали последнее.

Но время шло, сменилась власть, понемногу стала развиваться экономика. Сейчас становятся востребованными многие профессии, которые раньше были в загоне. И везде нужны профессиональные пользователи вычислительной техники. Поэтому «человек с клавиатурой» будет востребован всегда, область применения его навыков не ограничивается системным администрированием или программированием в чистом виде.

У большинства системных администраторов есть набор преимуществ, которые позволяют им легко адаптироваться на новом месте работы. В первую очередь это умение читать «скучные книжки». Бывшие сисадмины моментально адаптируются к изменившимся условиям работы, осваивают новые программы, прочитывают кучу документов. Подобная скорость обработки информации большинству из офисного планктона явно не по зубам.

Вторым преимуществом являются профессиональные навыки пользователя компьютера. Понятно, что человек, недостаточно хорошо умеющий использовать вычислительную технику, будет проигрывать тому, для кого «нет темных мест в цифровом царстве». Подготовить сложный отчет, нарисовать диаграмму, сверстать красивый, легко читаемый документ – да, пожалуйста! Для бывшего админа это легко.

Третьим неоспоримым преимуществом является знание английского языка, пусть даже письменного английского. Нередко трудно найти бухгалтера или финансового аналитика хотя бы с первичным знанием английского. Поэтому бывшие сисадмины и здесь легко обходят конкурентов.

Четвертым преимуществом является колоссальная работоспособность системного администратора, выработанная во время «двойных рабочих дней». Большинство нормальных людей не в состоянии выдержать хотя бы несколько недель подобной нагрузки, которую бывшие админы вынуждены терпеть годами, изредка прерываясь на «виртуальный отпуск».

Конечно, обладая вышеперечисленными навыками, бывшие админы легко обходят на поворотах своих «не технических» коллег. Теперь немного о путях смены профессии.

В первую очередь имеет смысл присмотреться к освобождающимся вакансиям на своем предприятии. Я знаю несколько успешных примеров, когда сотрудники отдела ИТ переходили в другие подразделения и весьма неплохо себя при этом ощущали. Работодатели часто предпочитают взять к себе проверенного человека, знающего структуру предприятия, нежели искать его на стороне. Я знал бывшего админа, перешедшего работать в отдел поставок в своей же фирме. Начал с должности рядового менеджера и очень быстро стал начальником отдела. Сейчас он директор по вопросам логистики крупной компании.

Другой пример – инженер техподдержки, обслуживал кассовые аппараты. Стал рядовым менеджером по продажам. За год вырос до начальника отдела по работе с клиентами. Третий пример – бывший системный администратор, по долгу службы ему приходилось много и часто разбираться с вопросами «1С». В итоге он стал заместителем главного бухгалтера, а потом и вовсе главбухом фирмы. Несколько лет назад купил себе квартиру в Москве. Еще пример – сисадмин-техсаппорт. Имел хорошие отношения с начальником отдела, связанного с рисованием всяческих схем, планов и тому подобных вещей. Когда увольнялся, зашел попрощаться. Учитывая, что с графическими программами у бывшего админа было все о'кей, начальник отдела тут же предложил ему новую вакансию. Ушел техсаппорт из компании только через пять лет в должности начальника отдела на более высокооплачиваемую работу. Как видите, подобная горизонтальная миграция в пределах одной компании вполне возможна и даже приветствуется.

Другой путь состоит в получении дополнительного образования по выбранному направлению, не связанному напрямую с ИТ. Например, получение степени MBA в области рекламы и маркетинга. Конечно, это удовольствие стоит довольно приличных денег. Именно поэтому я завел речь о том, чтобы выжать из своей профессии системного администратора все, что только возможно в плане финансов, и скопить некоторую сумму. Если вы сразу после получения диплома не будете претендовать на высокие оклады, можно без особого труда найти работу. Многие учебные заведения такого уровня помогают своим выпускникам найти работу. Ну, а дальше все зависит от вас. Кстати, помимо курсов MBA существует еще множество других возможностей переучиться на понравившуюся специальность и неплохо трудоустроиться после их окончания. Существуют и бесплатные «лазейки». Например, можно бесплатно окончить курсы бухгалтеров или программистов «1С» при службе занятости и даже получить первую работу.

Третий путь – просто попытаться трудоустроиться на вакансию по выбранной профессии. Многие консультанты по трудоустройству советуют вспомнить свое хобби. Большинство представителей из числа системных администраторов отнюдь не являются «упертыми технарями». Кто-то любит рисовать и работать с компьютерной графикой, кто-то серьезно интересуется экономикой, кто-то владеет дополнительным иностранным языком, кто-то просто имеет неплохо подвешенный язык. Если при трудоустройстве сразу не претендовать на высокий уровень дохода, можно вполне удачно найти работу и заниматься любимым делом, получая за это деньги.

Есть еще один путь, довольно простой и надежный, который многие отвергают по ряду психологических причин. Это избрать для себя рабочую специальность. Ну, не нужно нашей стране сегодня столько системных администраторов, сетевых инженеров, начальников ИТ-отделов и ИТ-директоров. Не та структура экономики. Я уже писал про отставание России в технических вопросах. Понятно, что офисным сотрудникам, в том числе системному администратору, психологически трудно принять тот факт, что соседский Витек с девятью классами и ПТУ за плечами может зарабатывать больше, чем системный администратор с высшим образованием, сертификатом от Microsoft и пятилетним стажем, однако это правда жизни. Профессиональные сварщики, автомеханики и даже сантехники могут получать гораздо больше офисного сисадмина, при этом не имея по двойному рабочему дню и не рискуя сесть в тюрьму.

Конечно, при любом раскладе первый год-два вы можете потерять в зарплате. Именно поэтому неплохо иметь соответствующий запас денег, не проедать его, а тратить обдуманно. Вкупе с оплатой переобучения это и есть та самая реинвестиция в новую профессию, о которой шла речь выше. Со временем материальная ситуация выправится. Года через три вы, скорее всего, будете с усмешкой вспоминать свои сисадминские проблемы, в том числе и вечное безденежье. И в любом случае не будете подвергаться опасности получить срок за нелицензионное программное обеспечение или сокрытие чужих махинаций. Как сказал один мой друг, ныне успешный менеджер по продажам: «Лучше быть дворником и приносить жене зарплату, чем получать от нее передачи в тюрьму, купленные на деньги из детского пособия».

Существует еще один фактор, который удерживает системных администраторов от смены профессии. Это страх прослыть слабаком. Мол, не потянул, мозгов не хватило, неудачник… Во все времена именно самые смелые, умные, решительные люди покидают обжитые места, чтобы «заглянуть за горизонт». Неудачник – это не тот, кто сделал шаг в незнакомую для себя область, а тот, кто не может оторваться от насиженного места.

Возможность вторая. Скрытно для глаз, короткими перебежками

Но иногда бывает затруднительно вот так сразу сменить профессию. Что делать в этом случае? Можно попробовать перейти в смежную специальность. Тестировщик, программист на стартовую позицию, технический писатель – востребованные профессии, куда без особого труда может устроиться бывший системный администратор. Сразу высокий оклад, конечно, никто не обещает, но со временем можно продвинуться в профессиональных навыках и сделать неплохую карьеру. Средний доход российского программиста выше, чем у системного администратора. Кроме того, в софтверных компаниях возможна не только горизонтальная, но и вертикальная карьера. Помимо этого, у программиста иногда появляются неплохие возможности подзаработать на стороне. В отличие от системного администратора, который воспринимается исключительно как обслуживающий персонал и должен быть всегда под рукой, к удаленной разработке программного обеспечения сторонним программистом российский предприниматель относится вполне лояльно, особенно если это обходится дешевле оплаты штатного программиста.

Еще одна неплохая сфера применения – веб-дизайн и веб-программирование. Здесь у бывших системных администраторов есть преимущество в знании особенностей работы сетевых протоколов и основных сетевых сервисов. Многие сисадмины так или иначе вынуждены понимать Perl и/или PHP, уметь разбирать java-скрипты и т.д. Поэтому переход в данную область не столь затруднен, а выгода вполне ощутимая.

С чего начать? Например, можно присмотреться к работе местных программистов, если такие имеются в поле зрения. Постепенно можно начать изучать язык программирования, который компания использует для решения бизнес-задач. Если у вас будет получаться – можно выходить с предложением помочь бухгалтерии. Конечно, на первое время вы вешаете себе лишний хомут на шею. Но когда ваши навыки будут расти, вы сможете полностью сменить специальность.

Еще вариант – просто прочесть книжку по программированию на выбранном языке и выполнить упражнения, описанные в ней. Постепенно поднять свои знания, сдать экзамены на соответствующий сертификат. С сертификатом и опытом работы системным администратором уже можно претендовать на кое-какое рабочее место.

Помимо программирования существует множество других интересных и не самых убогих в плане материального вознаграждения специальностей. Например, телефония. Знание продуктов Avaya, Siemens всегда востребовано не только в системных интеграторах, но и в крупных коммерческих компаниях. При этом, естественно, гораздо меньше проблем, связанных с законом, «двойным рабочим днем» и другими факторами.

Я нарочно не пишу о переходе на работу в системный интегратор. На мой взгляд, аутсорсинг в России находится в зачаточном состоянии. Сегодня большинству компаний выгоднее иметь офисного раба в лице сисадмина, чем цивилизованно вести переговоры с представителями аутсорсера.

Возможность третья. Воспитание нелояльности

В движении будь как вода,
Как зеркало будь неподвижен.
Отвечай, отзываясь как эхо,
Будь тонким, как не существуя.

Даосское стихотворение

Еще один способ поднять свой материальный уровень и повысить статус – сменить работу. Однако это не решение проблем, а всего лишь отсрочка. Тех, кто еще надеется, что сможет избежать проблем с законом, могу разочаровать: по-настоящему «белых» компаний очень и очень мало. Даже те фирмы, которые используют стопроцентно лицензионное программное обеспечение, могут иметь «черную бухгалтерию» и другие неприятные вещи. В итоге системному администратору все равно придется прикрывать бизнесмена, рискуя своей свободой.

Не нужно ждать милостей от работодателя, проявлять чудеса лояльности. Читайте приведенную выше древнюю восточную мудрость и поступайте согласно указанным в ней правилам. Работодатель должен понимать, что обращаться с системным администратором как с офисной прислугой и платить ему гроши у него не выйдет. Что у вас есть гордость «хлопнуть дверью» и вы при этом не умрете с голоду, несмотря на все экономические кризисы. В то же время переход в другую компанию на более высокооплачиваемую вакансию можно рассматривать как инвестицию в процесс полной переквалификации и смены профессии.

Большинство современных работодателей с неохотой берут на работу специалистов, которые склонны часто менять работу. По их мнению, наемный сотрудник должен быть исключительно лоялен к компании, в то время как бизнесмен может некорректно обащаться с наемными сотрудниками. Такое крепостничество должно получить адекватный ответ в виде постоянной готовности сменить компанию. Но бравировать этим нельзя. Нужно просто постоянно искать работу. Постоянный мониторинг рынка труда, поиск интересных вакансий должен занять важное место в вашей жизни. Если компания не контролирует посещение интернет-сайтов, я рекомендую начинать и заканчивать рабочий день с просмотра новых вакансий и откликов на резюме. В противном случае то же самое необходимо ежедневно делать из дома.

Но это еще не все. Казалось бы, чего проще: накатал резюме, разместил на «работном» сайте – и сиди, жди писем и звонков. Однако не все так просто. Многие компании отслеживают резюме своих сотрудников. Чтобы ваша работа не попрощалась с вами раньше времени, нужно проявлять определенную осторожность. Например, купить еще один мобильный с другим номером телефона. Завести абсолютно новый e-mail и везде размещать только его. Не публиковать личных сведений о себе.

Имеет смысл слегка исказить свои данные, по которым может осуществляться поиск, – например, сделать «опечатку» в фамилии, дате рождения и т.д. Ни в коем случае нельзя указывать реквизиты текущего места работы. Многие менеджеры по персоналу запросто могут позвонить по рабочему телефону, представиться и пригласить вас к телефону. Другой сюрприз, который можно ждать от HR, – звонок на работу, чтобы получить дополнительные сведения о вас. Поэтому лучше в качестве текущего места работы указать в резюме, скажем, «крупная российская компания», «известный банк» и т.д. Рекомендатели (если они у вас есть) тоже должны быть с предыдущего, а не с нынешнего места работы. При поиске работы вы должны быть «тонким, как не существуя».

Что еще ни в коем случае не надо делать – выбегать с мобильным телефоном в коридор при звонке от потенциального работодателя. Просто все прекрасно знают, что так поступает человек, который ищет работу и не хочет, чтобы об этом догадывались. Спокойно попросите написать письмо на e-mail, указанный в резюме, и мило завершайте беседу. Придумайте себе предлог, чтобы отлучаться из офиса. Многие сисадмины используют свой отпуск для поиска работы. Это более безопасно, чем отлучаться из офиса на собеседования.

Если к вам относятся пренебрежительно, мало платят, над вами висит угроза привлечения к суду, нужно в любой момент быть готовым сменить работодателя, то есть постоянно быть в движении. Если на текущей работе к вам очень хорошо относятся, платят по-настоящему достойную зарплату, компания использует исключительно лицензионное ПО – наверное, имеет смысл задержаться в этой компании подольше. В любом случае вы должны, подобно горному эху, чутко улавливать колебания и своевременно на них реагировать.

Чтобы успокоить тех, кто боится прослыть «бегуном», могу заверить, что это не самое страшное. Гораздо страшнее получить репутацию «сидуна» – человека, не умеющего адаптироваться к новым условиям и поэтому работающего на одном месте рекордно долгий срок. Рано или поздно им все равно приходится покидать компанию, в которой они работали, например, по причине ее ликвидации. Поэтому вы всегда должны быть готовы положить на стол своему работодатели заявление об уходе со словами: «Ничего личного, только бизнес».

Понимание – путь к прозрению

– Вы, системные администраторы, прямо как врачи-гинекологи…
– Это почему?
– Потому что в приличном обществе о ваших проблемах не говорят!

Такой вот занятный разговор состоялся с представителем руководства одной компании. А ведь действительно, большинству людей наши проблемы непонятны и неинтересны. А знаете почему? Потому что в них не говорится о деньгах! Когда бизнесмен рассматривает произведение искусства, он в первую очередь поинтересуется тем, сколько это стоит. Говорите и вы о деньгах. Анализируйте риски, прикидывайте утраченную выгоду. Я открою страшную тайну: многие так называемые экономисты, окончившие платные вузы, не в состоянии нарисовать в качестве примера кривые спроса и предложения. Поэтому вы со своим расчетом если и попадете пальцем в небо, то это, кроме вас, мало кто сможет заметить.

Еще одна ошибка, которую допускают ИТ-специалисты, – это самоизоляция ИТ-подразделения. Получается, что никто не знает, чем эти «айтишники» там занимаются. Отсюда и байки про «компьютерных гениев» и «обслуживающий персонал». Полностью от подобного непонимания вы не избавитесь, но снизить его степень не так уж сложно. Для начала напишите отчет о проделанной работе, понятный вашему руководству. Пусть там будут приятные для глаз цифры о сэкономленных ресурсах и предотвращенных убытках. Пусть там будет перечень работ, которые вы провели во внеурочное время. А в конце года можно сделать небольшую презентацию. Не получится выступить – разошлите по почте. Преподнесите свою работу в выгодном ключе. Не так это сложно, учитывая все, что было написано выше. Возможно, вместе с пониманием придет и желание помочь с решением проблем. И если не получится – перечитайте материал по поводу смены профессии или хотя бы компании.

«Админь головой, а не ногами»

Это просторечие содержит в себе весьма мудрую мысль. Очень часто в связи с невысокой квалификацией и плохой организацией труда инженер техподдержки и даже системный администратор, что называется, бегают по пользователям. Пользователь позвонил – сисадмин прибежал. Чтобы так не получалось, используйте средства удаленного управления. Для непосредственного визуального управления «рабочим столом» и помощи пользователям системы управления на базе VNC (Virtual Network Computing). Например, для управления средой на базе Windows подойдет бесплатная программа UltraVNC (официальный сайт http://www.uvnc.com). Для скрытого управления можно использовать telnet и командную строку. GPO в Active Directory позволяет творить изумительные вещи. Если не хватает этих ресурсов, можно «подбросить» пользователю ключ через удаленное управление реестром. MMC-консоль также позволяет делать интересные вещи. В случае c UNIX-подобными операционными системами можно применять традиционный SSH, VNC (это кросс-платформенное решение), а также средства X-Window сервера. При наличии таких мощных инструментов общение с пользователями в идеале должно быть сведено к минимуму. Теперь вы уже не «мальчик по вызову», а именно администратор системы, который видит все элементы инфраструктуры и всех пользователей «как на ладони». Осознание этого факта способно заставить даже самого недалекого пользователя относиться с уважением к представителю ИТ-службы. И уж конечно, вы не должны мстить своим пользователям, используя эту систему.

Вообще лучше стараться не допускать проблему, чем срочно устранять ее. Специалист, у которого все работает, производит гораздо меньшее впечатление «обслуживающего персонала», чем тот, который бегает в мыле, без конца устраняя сбои системы.

Решите, наконец, проблему с печатью документов! Организуйте своевременную замену картриджей не тогда, когда приперло, а заблаговременно. Также вовремя сдавайте технику в ремонт. Напишите элементарные инструкции для пользователей и развесьте их рядом с техникой. Если вы сделали все необходимое, но все равно находятся люди, не желающие грамотно обращаться с техникой, – тогда можно с чистой совестью нажаловаться руководству.

Если же в организации, где вы работаете, просто не выделяются деньги на ремонт, замену комплектующих, покупку расходных материалов и другие необходимые вещи – смело меняйте работодателя.

***

Я нарочно не рассматривал в этой статье такие вопросы, как эмиграция в развитые страны, освоение денежных сисадминских специальностей, таких как специалист по продуктам Cisco Systems и так далее. Потому что, во-первых, эти пути многим известны, во-вторых, как говорил небезызвестный Козьма Прутков: «Невозможно объять необъятное».

Наверняка после прочтения статьи у читателя сложилось гнетущее впечатление. Но сегодня дела в области системного администрирования обстоят примерно так, с поправкой на местные факторы. Кто-то работает в «белой конторе» за небольшую зарплату, кто-то вроде и получает неплохо, но сидит и дрожит, опасаясь проверки и судебного разбирательства. А кто-то и денег нормальных не получает, и свободой понапрасну рискует. На кого-то орут как на прислугу, а кто-то свысока поглядывает на пользователей… Ситуация может отличаться, но суть остается. И если из сотни прочитавших эту статью десять системных администраторов задумаются, а один из этих десяти сумеет хоть немного изменить свою жизнь к лучшему, я буду считать, что мой труд не пропал даром.

Ссылки:

Полезные ресурс для сисадмина и вебмастера

anonymous@undisclosed.example.com (Anonymous) — Tue, 09 May 2017 15:34:00 +0000

Полезные ресурс для сисадмина и вебмастера

http://www.manageserver.ru/ - «Повелитель серверов», большое сборище прикладной информации
http://www.pro100hosting.ru - сто советов вебмастеру

Философия работы отдела ИТ

anonymous@undisclosed.example.com (Anonymous) — Sat, 13 Oct 2018 16:11:51 +0000

Философия работы отдела ИТ

Делать нужно так, как нужно. А как не нужно - делать не нужно. И как следствие меня всегда потом прикалывает, что большинство людей, как правило, не понимают очень простой вещи: Если всё время делать, так, как проще / быстрее, а не как нужно, то довольно быстро наступит момент, когда выбор будет крайне прост: или дорого, долго, сложно, или никак вообще. Богданов Р.Ю.

Следует ясно и четко понимать, что разруха — она в головах, а не в сортирах. У нас техника рассматривается как бремя в силу безграмотности, нежеланию учиться, низменности жизненных целей и непониманию сути происходящего.

10 памяток для сисадмина

Делать все просто, сложные системы ломаются быстрее.
Регулярные бэкапы.
Проверять состояние бэкапов!
Мониторить все что можно.
Документировать все что делается/создается/изменяется.
Сначала планируем, потом делаем.
Используем по максимуму командную строку, GUI - необходимый минимум.
Автоматизировать все что возможно.
Пользователи как цыплята - им должно быть сухо, комфортно и уютно. И они должны знать, что стоит высунуться из-под крыла - получишь клювом в лоб.
Не стоять на месте, изучать и внедрять все новое. А главное - получать от этого fun.

ит, it, философия, сисадмину

Тест Лимончелли: 32 краеугольных принципа хорошей ...

anonymous@undisclosed.example.com (Anonymous) — Tue, 09 May 2017 15:34:00 +0000

Тест Лимончелли: 32 краеугольных принципа хорошей команды системного администрирования

http://ivanpesin.info/translations/other/32LimoncelliTest.html

The Limoncelli Test – 32 bedrock issues of a well-functioning sysadmin teams

URL: http://everythingsysadmin.com/the-test.html

Автор: Том Лимончелли (Tom Limoncelli)

Перевод: Иван Песин (Ivan Pesin)

Лицензия: Creative Commons License

Sun Nov 6 10:26:30 EST 2011

Меня часто спрашивают, как улучшить работу системных администраторов. Требуется немного времени, чтобы обнаружить фундаментальные пробелы, исправив которые можно улучшить продуктивность и качество работы системных администраторов.

Такие пробелы не просто создают много проблем, они создают много категорий проблем.

Например: использование системы отслеживания запросов (request tracking system или «ticket system») — фундаментальная техника. Она принесет вашей команде много очевидной, и не совсем, пользы. Без неё вы рискуете столкнуться с разными категориями проблем: проблем в результате забытых запросов; проблем из-за того, что пользователи отрывают вас от работы по любому поводу; проблем из-за незнания руководством, чем занимается ваша команда; проблем из-за невозможности обнаружить тенденции; проблем команды, которая не может эффективно передавать задачи.

Исправление фундаментальных пробелов выглядит трудным делом, но если их оставить неисправленными, то это выльется для вас в ещё большее количество работы.

Джоэль Спольски написал блестящий «Тест Джоэла: 12 шагов к лучшему коду”, «…совершенно безответственный и несерьёзный тест для определения качества команды разработчиков», состоящий из 12 вопросов. Я придумал собственный тест для системных администраторов. Он состоит из 32 односложных вопросов. И он такой же безответственный и несерьёзный.

Цель этого теста — упростить общую оценку команды СА. Он будет полезен и руководителю команды, и ведущим специалистам, и рядовым членам команды. Тест также может служить способом оценки потенциального места работы: если вы не хотите присоединиться к кораблю дураков, вы должны выяснить у вашего возможного работодателя, какие из практик они используют, а какие — нет. И не так важно, сколько они набирают очков, как отношение: нежелание или невозможность изменений сигнализирует опасность.

Очевидная проблема этого теста в том, что он в 3.2 раза длиннее теста Джоэла. Он достаточно гениален, чтобы свести свой к 10 вопросам. В свое оправдание, хочу сказать, что изначально в моем тесте было 40 вопросов.

Разделы, помеченные звёздочкой — самые фундаментальные. Соответствующие практики в моей книге обозначены, как абсолютно необходимые. Остальные тоже важны, но могут быть нерелевантны для маленьких фирм.

Сколько очков у вас?

Тест Лимончелли: 32 вопроса к вашей команде сисадминов

Обновлено: 2011-07-25

A. Подходы по работе с пользователями:

*1. Используете ли вы систему отслеживания запросов?

*2. Есть ли у вас “три регламентирующие политики” и знают ли о них?

3. Ведёт ли команда ежемесячные метрики?

B. Современные подходы в работе:

*4. Есть ли у вас вики с описанием политик и процедур?

5. Есть ли у вас место, где хранятся пароли?

6. Хранится ли ваш код в системе управления версиями?

7. Использует ли ваша команда систему отслеживания ошибок для своего кода?

8. В ваших задачах обеспечение стабильности приоритетнее новых возможностей?

9. Пишет ли ваша команда проектную документацию?

10. Выполняете ли вы анализ причин происшествия?

C. Операционные подходы:

*11. Есть ли у вас документация (OpsDoc) на все ваши сервисы?

*12. Имеет ли каждый сервис необходимый мониторинг?

13. Есть ли у вас график дежурств?

14. Используете ли вы отдельные системы для разработки, тестирования и производства?

15. Используется ли “канареечный процесс” при внесении изменений на большое количество машин?

D. Подходы по автоматизации:

16. Используете ли вы инструменты управления конфигурацией, такие как cfengine/puppet/chef?

17. Выполняются ли автоматизированные задачи под ролевыми учетными записями?

18. Ваши автоматизированные задачи шлют почту только когда есть полезная информация?

E. Подходы по управлению парком машин:

*19. Есть ли у вас база данных всех машин?

20. Автоматизирован ли у вас процесс установки ОС?

*21. Можете ли вы автоматически обновлять ПО для всего парка машин?

22. Есть ли у вас политика обновления компьютеров?

F. Подходы серии “Мы согласны, что техника ломается”:

*23. Будут ли работать ваши сервера, если на них откажет один из дисков?

24. Используется ли схема N+1 в ядре вашей сети?

*25. Автоматизировано ли ваша процедура резервного копирования?

*26. Проверяете ли вы периодически свой план аварийного восстановления?

27. Есть ли в вашем ЦОД системы удаленного управления питанием и доступа к консолям?

G. Подходы к безопасности:

*28. Ваши сервера/ноутбуки/компьютеры защищены автоматически обновляемым антивирусным ПО?

*29. Есть ли у вас политика безопасности в письменном виде?

30. Проводите ли вы регулярный аудит безопасности?

31. Можете ли вы отключить учетную запись пользователя во всех системах за 1 час?

32. Можете ли вы сменить все привилегированные (root) пароли за 1 час?

A. Подходы по работе с пользователями:

*1. Используете ли вы систему отслеживания запросов?

Это настолько фундаментальная практика, что меня гнетет необходимость пояснений.

Люди не обладают такой хорошей памятью, как компьютеры. Ожидать от сисадминов, что они будут помнить все запросы пользователей, это прямой путь к тому, что запросы будут забываться.

Хранение запросов в базе упрощает обмен информацией в команде и позволяет избегать ситуаций, когда два человека одновременно работают над одним и тем же запросом, дает возможность делить работу межу людьми, передавать работу между собой, не теряя информации, и подменять администратора, который недоступен, вышел или в отпуске.

Эта практика делает работу команды прозрачнее. Пользователи видят кто работает над запросом, какой у него статус, и когда он выполнен. Это позволяет пользователю и администратору задавать дополнительные вопросы и следить за ответами.

Использование системы учета запросов позволяет эффективнее использовать рабочее время. Каждый раз, когда сисадмина отрывают от того, что он делает, его отбрасывает на 7 минут назад в задаче, от которой его оторвали. Система учета запросов уменьшает количество прерываний от пользователей, которые хотят сделать новый запрос или узнать статус открытого запроса. Она также позволяет задавать приоритеты в работе администратора, а не решать проблемы пользователя, который жалуется громче всех.

Подход с учетом запросов дает возможность менеджерам стать лучше. Затормозившиеся запросы сразу становятся видны и менеджер имеет возможность вмешаться. Вскрываются тенденции и частые запросы, что позволяет оптимизировать работу с помощью автоматизации или улучшения процесса. Микроменеджеры могут получить информацию из базы запросов, не отрывая администраторов от работы. Жалобы пользователей приобретают обоснованность: если запрос решается слишком долго, менеджер может надлежащим образом решить вопрос; если пользователю только кажется, что запрос долго решается, то у вас будут доказательства противного. Если пользователь заявит, что “эта проблема тянется месяцы, но я только вчера прислал запрос”, то у менеджера будет возможность… пояснить, что путешествие во времени, телепатия и другие сверхъестественные возможности в природе не существуют.

Система учета позволяет обнаружить системные проблемы. Однажды у меня был шеф, который, выполнив запрос в системе учета, обнаружил, что 3 из наших 1000 пользователей создали 10% всех запросов. Проведя небольшое расследование, мы смогли решить некоторые фундаментальные проблемы, которые были причиной этих запросов.

Наконец, такая система позволяет пользователям помогать самим себе. Часто бывает, что когда пользователь формулирует проблему, он сам находит ее решение и запрос так и не отправляется. Если же этого не происходит, то сам процесс помогает пользователю продумать проблему и сформулировать ее яснее, что ускоряет решение проблемы.

Я провел 90-е года в роли радикала, убеждающего людей использовать системы отслеживания запросов. В 2000-х, я с удовольствием наблюдал, как это становится общепринятой практикой. Наступила третья декада и если у вас до сих пор нет системы отслеживания запросов — позор вам.

Подробнее:

  TM: p. 26, Chapter 2: Focus Versus Interruptions / Delegate, Record, Do
  P2: p. 28, Chapter 2: Climb Out of the Hole / 2.1.1 Use a Trouble-Ticket System
  P2: p. 354, Chapter 13: Helpdesks / 13.1.10 Supply Request-Tracking Software

*2. Есть ли у вас “три регламентирующие политики” и знают ли о них?

Если вы хотите, чтобы работа делалась, вам нужно определить три политики, регламентирующих вашу работу с пользователями. Они направлены как на обслуживание клиентов, так и на обеспечение эффективной работы команды сисадминов. Если вы, как менеджер команды сисадминов, считаете, что она ничего не успевает, возможно, это ваша вина, если вы не определили или не выполняете эти три политики:

  Доступные пользователям способы запроса помощи.
  Определение "аварийной ситуации".
  Объем обслуживания: кто, что и где.

Эти политики помещаются на одной страничке и она должна быть доступна на веб-сайте вашей команды или развешана на стенах, чтобы их знали. Руководство должно поддерживать эти политики; это значит, что менеджмент готов сказать “нет” людям, когда они просят сделать исключение. Процесс получения исключения должен быть похож на пробивание стены, а не на проезд “спящего полицейского”.

Как получить помощь:

Официальный протокол, описывающий как пользователи должны запрашивать помощь, позволяет получить все преимущества использования системы отслеживания запросов, описанные в предыдущем разделе. Без этой политики все преимущества испаряются, потому что люди будут приходить прямо к сисадминам, которые, стараясь помочь, будут постоянно отвлекаться на мелочи, а их эффективность сильно понизится.

У системного администратора должны быть возможность отказать пользователю, когда тот не соблюдает протокол. Без возможности отослать пользователя к официальной политике, администраторы будут работать либо над низкоприоритетными задачами, либо для пользователей, которые громче всех жалуются, либо каждый из них будет пользоваться своей личной политикой, тем самым выставляя всю команду непоследовательной, а в худшем случае будут нездоровым способом демонстрировать свое неудовлетворение. Точнее, нездоровым для пользователей способом.

Определение аварии:

Официальное определение аварийной ситуации позволяет системным администраторам расставлять приоритеты. Без этого определения, всё становится авралом, и снова сисадмины будут постоянно отвлекаться на мелочи, а их эффективность сильно понизится.

Политика — это один из способов, которым руководство коммуницирует приоритеты системным администраторам. В противном случае, сисадмины будут строить догадки о приоритетах, ошибаться, их будут несправедливо за это наказывать; менеджеры будут расстраиваться из-за “дисконнектов”, а пользователи, видя непоследовательность, будут предполагать фаворитизм, халатность и некомпетентность.

Это политика определяет ожидания пользователей. С ее помощью можно корректировать иллюзии пользователей, которые считают любой происшествие аварийной ситуацией.

Каждая организация должна иметь определение аварии или “красного сигнала”. Для газеты — это все, что блокирует печать завтрашнего номера и его погрузку в грузовики в 4 утра. “Красный сигнал” на заводе — это все, что останавливает конвейер. Авария для отдела платежей — все, что делает невозможным проведение платежей. Команды, работающие в сфере образования, знают, что перенести занятие совсем не просто, потому аварийной ситуацией является все, что мешает надлежащему проведению лекции (возможно, только если технологический центр был заблаговременно предупрежден). В университетах “красный сигнал” определен, как любая преграда для своевременной подачи заявок на получение грантов.

“Желтый сигнал” — это все, что приведет к “красному”, если останется без внимания. Например, оплаты проводятся, но не работает подсистема оценки доступных запасов. В таком случае очень рискованно брать новых клиентов. Последняя оценка говорила о запасах, достаточных на 2 недели. Риск остановки производства растет с каждым днем, пока “желтый сигнал” не будет исправлен.

Все остальное — это рутина. Изобретательные компании разделяют рутинные задачи по приоритетам: высокий, средний, низкий; создание нового сервиса, поддержка существующих, и т.д. Если у вас ничего такого нету, начните с определения, что представляет собой авария.

Что поддерживается:

Официальное определение поддерживаемых сервисов позволяет администраторам говорить “нет”. Должно быть определено когда, где, кто и что поддерживается. Работает ли команда после 6 вечера? На выходных? Ходят ли администраторы по вызову к рабочему месту пользователя? Домой к пользователю? Поддерживаете ли вы кого-либо, кроме сотрудников компании? Какое программное и аппаратное обеспечение поддерживается? Есть ли у поддерживаемого обеспечения жизненный цикл, или вы обречены его поддерживать вечно? Новые технологии включаются в поддержку автоматически или после официального утверждения?

Не имея возможности сказать “нет”, администраторы будут поддерживать всё. Отзывчивый и старательный сисадмин потратит кучу времени, пытаясь заставить работать неподдерживаемую видеокарту, при том, что дешевле будет подарить этому пользователю поддерживаемую карту за счет бюджета СА. Пропавший без вести системный администратор вдруг найдется, после дня, проведенного у пользователя дома, где он ремонтировал Интернет-подключение. Или наоборот, ворчливый сисадмин будет говорить людям, что они это не поддерживают, просто потому, что он занят.

Подробнее:

  TM: p. 21, Chapter 2: Focus Versus Interruptions / Directing Interruptions Away from You
  P2: p. 27, Chapter 2: Climb Out of the Hole
  P2: p. 820, Chapter 33: A Guide for Technical Managers / 33.1.1.1 Priorities and Resources

3. Ведёт ли команда ежемесячные метрики?

Когда вы принимаете решения или убеждаете в чём-то высшее руководство, вы должны руководствоваться данными.

Наилучший способ разработки метрик — это создание одной метрики на каждое предложение или пункт устава.

Пример: устав команды развёртывания рабочих мест может звучать как «Обеспечение высококачественным, стандартизированным компьютером каждого сотрудника с первого дня его работы, обновление компьютера на основе 3-х летнего цикла, по оптимальной эксплуатационной стоимости. Тогда метриками могут быть: количество недель с последнего обновления стандартной конфигурации, цена текущей стандартной конфигурации, количество новых сотрудников в этом месяце, капитальные расходы, операционные расходы. Сколько дней новые сотрудники ждали своего компьютера (группировка, когда был установлен компьютер: до прихода, в первый день, на второй день, на 3-й, 4-й, 5-й и больше, чем через 5 дней). Возраст парка (группировка по возрасту: меньше года, от 1 до 2 лет, от 2 до 3 лет, больше 3 лет). Число использующихся машин с нестандартной конфигурацией.

Если у вас нет устава, поговорите со своим менеджером про то, чтобы его написать. В качестве альтернативы, вот список простых «начальных метрик», которые вы можете начать вести немедленно:

  Сколько у нас системных администраторов?
  Сколько у нас пользователей, которым мы предоставляем сервис?
  Сколько компьютеров мы поддерживаем?
  Сколько у нас совокупного дискового пространства? ОЗУ? Ядер ЦПУ?
  Сколько у нас “открытых” тикетов в данный момент?
  Сколько новых тикетов было создано за последний месяц?
  Кто (или какой отдел) создал большинство тикетов в этом месяце?
  Среднее число тикетов на сисадмина за последний месяц?
  Выберите 4-5 важных SLA и отметьте насколько точно вы их выполняете.
  Статистика использования полосы Internet-подключения за последний месяц.

Записывайте эти метрики первого числа каждого месяца. Внесите их в электронную таблицу. Теперь вы сможете использовать эти данные во время бюджетирования или для презентаций, когда нужно объяснить, чем занимается ваша команда.

Вот и всё. Действительно. Учёт этих метрик есть разница между презентацией, начинающейся с графика роста количества машин в вашей сети, и фразой «Привет, меня зовут Джо и мы поддерживаем… э-э-м-м… кучу машин». Во время бюджетирования, способность ответить на эти базовые вопросы, является основой для других вопросов, таких как «Какова средняя стоимость тикета?» (сумма бюджета последнего года / общее количество тикетов за последний год). Если у нас будет 100 пользователей, сколько дискового пространства нам понадобится? ( общее дисковой пространство / количество пользователей * 100).

Сбор данных для метрик, в конечном счёте, должен быть автоматизирован. До того, настройте себе напоминание на почту, что это нужно сделать вручную.

Подробнее:

  P2: p. 523, Chapter 22: Service Monitoring
  P2: p. 119, Chapter 5: Services / 5.1.13 Monitoring
  P2: p. 765, Chapter 31: Perception and Visibility / The System Status Web Page
  P2: p. 849, Chapter 33: A Guide for Technical Managers / Sell Your Department to Senior Management

B. Современные подходы в работе:

*4. Есть ли у вас вики с описанием политик и процедур?

Вашей команде нужна вики. В ней можно написать все ваши политики (что должно выполняться) и процедуры (как это должно выполняться).

Автоматизация — это прекрасно, но перед тем, как автоматизировать что-то, вы должны мочь это выполнить вручную. Предусловием автоматизации является документирование ручного процесса. До того, документация дает возможность всей команде выполнять действия однотипно, а вам — делегировать задачи. Если процедура описана, ее может выполнить кто-то еще.

В оглавлении вики должны быть вынесены общие, рутинные задачи. Хорошо начать с процедур по добавлению/изменению/удалению, которые должны уметь делать все в команде, и задач, которые вы не любите выполнять и делегировали бы помощнику, если бы он был.

Список процедур:

  Приходит новый сотрудник.
  Сотрудник уходит из компании.
  Сотрудника увольняют.
  Установка нового компьютера.
  Компьютер выводится из эксплуатации.
  Как дать пользователю доступ через VPN.
  Как поменять диск в RAID-массиве.
  Как поменять root-пароль на всех машинах

Здесь включены три категории задач: вещи, в которых вам важно однообразие выполнения; вещи, которые вы редко делаете и не хотите каждый раз тратить время на то, чтобы вспоминать, как сделать правильно; и вещи, которые выполняются в стрессовых ситуациях, чтобы судорожно не думать над тем, что вы делаете.

Все эти три типа задач могут быть описаны простыми пошаговыми списками.

После того, как процедура описана, ее может выполнить каждый. Кроме того, такая документация, по сути, является программой обучения новых сотрудников. А еще ее можно использовать при составлении должностной инструкции для своего помощника, которого вы хотите чтобы компания наняла делать всю вашу работу.

Даже если вы не работаете в команде или есть задачи, которые делаете только вы, документирование имеет преимущества. Вам нужно будет меньше думать при выполнении задачи. Как правдива поговорка “мы автоматизируем, потому что ленивые”, так же правдива и поговорка “мы документируем, потому что нетерпеливые”.

Многие сисадмины не любят писать документацию, но составление пошагового списка не такая трудная задача. Важно держать документацию на вики, чтобы все могли ее исправлять и улучшать.

Для любой из задач можно иметь отдельные документы, описывающие политику и процедуру. Политику определяет руководство: “все новые пользователи должны получать беспроводную мышь”. Процедура определяет как это выполнять: “беспроводные мыши хранятся в 3-м ящике; зарядить и проверить так-то, и т.д.” Политика меняется только с разрешения руководства, процедура меняется техническим персоналом с уведомлением автора или других ответственных лиц.

Подробнее:

  P2: p. 241, Chapter 9: Documentation
  TM: p. 145, Chapter 12: Documentation

5. Есть ли у вас место, где хранятся пароли?

Это демонстрирует, что у вас есть зрелый способ управления паролями.

Существует много отличных программных систем хранения паролей. Однако часто достаточно просто держать конверт в обычном закрытом ящике.

Часто возникает проблема проверки паролей. Вы уверены, что злонамеренный сотрудник не вносит неправильные пароли? Если у вас есть основания для таких сомнений, нужно, чтобы кто-то третий проверял все новые пароли.

Подробнее:

  P2: p. 271, Chapter 11: Security Policy

6. Хранится ли ваш код в системе управления версиями?

С появлениям возможности установки новой системы при помощи API-вызова, мы теперь все программисты.

-Лимончелли о облачных вычислениях, devops, и важности навыков программиста в системном администрировании.

Мы теперь все программисты. Программисты используют системы управления версиями.

Что хранить в репозитории: ваши скрипты, программы, конфигурационные файлы, документацию — практически все что угодно. Если вы не уверены, стоит ли что-то держать в репозитории, ответ должен быть “стоит”.

Хранение конфигурационных файлов в системе управления версиями сначала выглядит как роскошь, но позже становиться спасительным средством.

Любая система лучше, чем ничего. Используйте то, чем пользуются ваши разработчики. Нет разработчиков? Выучите Git, Mercurial или даже Subversion. Срочно нужен быстрый способ хранить историю изменения конфигурационных файлов? http://www.nightcoder.com/code/xed (это враппер, который вызывает $EDITOR).

Подробнее:

  TM: p. 174, Chapter 13: Automation / xed

7. Использует ли ваша команда систему отслеживания ошибок для своего кода?

Системы отслеживания ошибок (bug-tracking system) отличаются от систем отслеживания запросов. Если у вас ошибки в коде появляются редко (например, ваша команда не пишет много кода), то достаточно просто открыть запрос для себя в системе отслеживания запросов.

Но если ваша команда пишет серьезный код, запустите отдельную систему отслеживания ошибок. Эти системы используют другой процесс, нежели системы отслеживания запросов. Запросы — это инструмент общения между вами и пользователями. Системы отслеживания ошибок отслеживают жизненный цикл ошибки (сообщение, проверка, назначение, исправление, закрытие, проверка).

8. В ваших задачах обеспечение стабильности приоритетнее новых возможностей?

Добавление функциональности всегда интереснее, чем исправление ошибок. К сожалению, мы не можем делать только то, что интересно.

Зрелые команды приоритезируют свои задачи следующим образом:

  безопасность (наивысший приоритет)
  стабильность
  ошибки
  производительность
  новая функциональность (низший приоритет)

Перед тем, как добавлять функциональность, вы должны добиться стабильности. Вопросы безопасности — это вопросы стабильности с наивысшим приоритетом.

Один из принципов, пропагандируемый Марком Бургессом (Mark Burgess), это «стремитесь к стабильности, а не к новой функциональности”. Среди изменений, которые мы делаем, одни — улучшают стабильность, другие — добавляют новые возможности. Последовательность должна быть такой: возможность, стабильность, возможность, стабильность, возможность, стабильность. Но не: возможность, возможность, возможность, ОЙ-ОЙ-ОЙ!, стабильность, стабильность, стабильность. Добейтесь стабильности перед тем, как внедрять очередную замечательную возможность.

Это понимают врачи. В реанимации сначала стабилизируют состояние пациента. Пациенту не лечат грипп, когда у него сильное кровотечение, от которого можно умереть

Приоритет проблем с производительностью варьируется. В некоторых местах производительность эквивалентна стабильности.

Подробнее:

  P2: p. 343, Chapter 33: A Guide for Technical Managers / Priorities
  TM: p. 101, Chapter 8: Prioritization / Prioritization

9. Пишет ли ваша команда проектную документацию?

Хорошие команды сисадминов сначала думают, потом делают. В больших командах важно коммуницировать, что вы собираетесь сделать или уже сделали.

Стандартным способом предложения новых систем или описанием существующих является проектная документация. Она может быть очень короткой — одна-две страницы, а может, при необходимости — очень детальной и исчерпывающей.

Создайте шаблон и используйте его везде. Он может содержать такие разделы: обзор, цели, ложные цели, предпосылки, решение, рассмотренные альтернативы, безопасность, аварийное восстановление, стоимость.

Этот формат можно использовать для написания 20-страничного плана реструктуризации вашей сети, когда вам нужно участие в этом многих людей. Его же можно использовать для 5-страничного документа, описывающего прототип, чтобы все могли видеть результат вашей работы и дать ему оценку, перед тем как внедрять его в эксплуатацию. И снова, этот формат можно взять для полстраничной заметки про новую структуру каталогов на файловом сервере (в этом случае, вам, вероятно, не понадобятся большинство разделов). Используйте его для документирования системы, которая уже запущена в работу, чтобы ваши коллеги могли использовать это описание, как справочник. Да что там, документируйте в этом формате даже ваши планы на пикник.

Идея в том, чтобы у вашей команды был механизм для размышления перед реализацией, способ обсудить планы, кроме общения в коридорах и митингрумах, система, которая позволяет сохранить информацию для других, кто захочет разобраться почему и как что-то было сделано.

Предложенный формат работает как для получения критических отзывов, так и для сообщения “предупредите меня, если то, что я собираюсь сделать, конфликтует с тем что делаете вы”.

Ваш формат проектной документации может содержать больше или меньше разделов, некоторые могут быть опциональными, другие — обязательными. Вы должны быть гибкими: если нужно полстраницы описания, не раздувайте текст так, чтобы в каждом разделе что-то было. Наличие стандартного шаблона упрощает процесс написания документа и позволяет избежать “синдрома пустой страницы”.

Подробнее:

  P2: p. 241, Chapter 9: Documentation

10. Выполняете ли вы анализ причин происшествия?

Регистрируете ли вы сбои с описанием того, что случилось, чтобы из них можно было что-то вынести, или вы просто надеетесь, что никто ничего не заметит, а проблема не повторится?

Хорошие анализ причин происшествия включает описание в разрезе времени, пострадавших, как была решена проблема, как происшествие повлияло на бизнес и список предложенных решений, для предотвращения повторного возникновения ситуации. Каждое предложение должно быть оформлено в виде тикета или отчета об ошибке, чтобы можно было отследить выполненные шаги.

Анализ причин последовательно формирует более стабильную среду. После каждого сбоя нужно придумывать хотя бы один превентивный ход. Может ли ваша система мониторинга определять проблему так, чтобы вы знали о ней до ваших пользователей? Можете ли вы обнаруживать предпосылки к возникновению проблемы? Во многих системах есть способ их тестировать на новых конфигурациях до внедрения (например, скрипты, выполняемые до добавления кода в репозиторий — pre-submit scripts — в системах управления кодом). Есть ли какие-либо тесты, которые вы могли бы добавить, чтобы обнаружить опечатку, ведущую к простою?

Цель проведения такого анализа не в нахождении виновных и их осуждении. В хорошей среде сисадминов нет ничего зазорного в том, чтобы указать свое имя в разделе “что мы сделали не так”. Этим вы выполняете роль лидера, просвещая людей для того, чтобы они не повторили ту же ошибку.

Если ваш менеджмент использует результаты анализа причин происшествия для того, чтобы наказать виновных, они не понимают, что цель эксплуатации не в том, чтобы работать идеально, а в том, чтобы работать лучше с каждым днем. Любой менеджер, увольняющий человека из-за того, что его действия привели к неумышленному простою, разваливает компанию.

Результаты анализа должны быть доступны всем. Вы можете смущаться и думать, что вы “выносите сор из избы”, но если это делать последовательно, ваши пользователи будут вас уважать больше. Прозрачность рождает доверие.

Ну и конечно, чтобы действительно воспитать уверенность, вы должны работать над всем этими проблемами и тикетами, которые появились в результате проблем.

Подробнее:

  P2: p. 492, Chapter 20: Maintenance Windows / 20.1.13 Postmortem

C. Операционные подходы:

*11. Есть ли у вас документация (OpsDoc) на все ваши сервисы?

Допустим у вас умирает DNS-сервер. Вы его переустанавливаете, ведь вы знаете, как это сделать. Круто, так? Вам нужно скомпилировать и установить последнюю версию BIND, и вы тоже знаете, как это сделать, так? А когда система мониторинга рапортует, что периодически возникает ошибка, вы знаете, как ее исправить, так ведь? Вы знаете, как все это делать. Зачем все это записывать?

Вот зачем:

Будете ли вы помнить все эти мелочи через 6 месяцев? Мне приходится переизобретать процесс с нуля, если я его не выполнял несколько месяцев (а иногда даже несколько дней!). И не только переизобретать, но и повторять старые ошибки и снова делать выводы из них. Время, потраченное в никуда!

А будете ли вы помнить, как все это сделать в стрессовой ситуации? Когда происходит внештатная ситуация, моя память работает хуже.

А что, если вас не будет на месте? Как можно расслабиться в отпуске, когда может случиться, что, кроме вас, никто не сможет справиться с проблемой? Нельзя жаловаться на перегрузку из-за невозможности передать свою работу другим, если вы не сделали это возможным.

Как на счет других людей в команде? Они должны учится, наблюдая, как вы делаете, или они могут учиться самостоятельно? Если они будут учиться самостоятельно, обращаясь за помощью, когда они зашли в глухой угол, это сэкономит вам время, а кроме того, вы не будете выглядеть скрягой, который не хочет делиться информацией — это же не ваша цель? Фактически, если у команды есть такого рода инструкции, то новички будут чувствовать себя комфортнее и быстрее включатся в работу.

Как может ваш менеджер повысить вас или перевести на новый и интересный проект, если вы единственный, кто имеет знания по текущему?

Каждый сервис должен иметь документацию по определенным вещам. Если документация по каждому сервису организована одинаково, люди к этому привыкают и могут быстрее найти нужную им информацию. Я делаю раздел на вики (или мини-сайт, или сайт на Google Sites) для каждого сервиса:

Каждый содержит 7 одних и тех же вкладок (некоторые могут быть пустыми):

1. Обзор: Обзор сервиса — что это такое, зачем оно нам нужно, контактная особа, как сообщить об ошибках, ссылки на документ с дизайном сервиса и другую соответствующую информацию.

2. Сборка: Как собрать программное обеспечение, которое предоставляет сервис. Откуда его загружать, где находится репозиторий исходного кода, шаги по сборке пакета для дистрибутива. Если вы каким-либо образом модифицируете это ПО (проект с открытым исходным кодом в котором вы участвуете или внутренний проект), добавьте вводную инструкцию для новых разработчиков. В идеале это должен быть установочный пакет, который нужно просто скопировать и установить на машине нового разработчика.

3. Развертывание: Как развернуть программное обеспечение. Как установить сервер с нуля: требования к памяти/диску, версия и конфигурация ОС, какие пакеты нужны, и т. д. Если это автоматизировано с помощью системы управления конфигурацией, такой как cfengine/puppet/chef (как и должно быть), так и укажите.

4. Общие задачи: пошаговые инструкции для таких общих задач, как инициализация (добавление/изменение/удаление), общие проблемы и их решения, и так далее.

5. План нотификаций (Pager Playbook): список всех нотификаций, которые может сгенерировать ваша система мониторинга для этого сервиса и пошаговые инструкции серии “что делать, когда” для каждой их них.

6. DR: План аварийного восстановления (Disaster Recovery). Если сервер с этим сервисом выходит из строя, как перенести сервис на резервный сервер.

7. SLA: Соглашение об уровне обслуживания (Service Level Agreement). Это (социальный или настоящий) договор между вами и вашими пользователями. Обычно, это вещи, вроде целевого аптайма (сколько девяток), RPO (Recovery Point Objective, целевая точка восстановления) и RTO (Recovery Time Objective, целевое время восстановления).

Если сервис разрабатывается вами, восьмая вкладка должна включать информацию для команды: как настроить среду разработки, как выполнять интеграционное тестирование, как готовить релизы и другие советы разработчикам. Например, один из проектов, которыми я занимаюсь, содержит четкий список шагов для добавления в систему нового удаленного вызова процедуры (RPC).

Будьте героем и создайте шаблон для вашей команды. Опишите, для начала, какой-нибудь основной сервис, например DNS. Потом, опишите сервис побольше. Создайте костяк, который другие будут использовать, как основу, и вписывать недостающие части. Возьмите в привычку начинать с сервисной документации каждый новый проект.

Подробнее:

  P2: p. 241, Chapter 9: Documentation

*12. Имеет ли каждый сервис необходимый мониторинг?

Сервис, который не мониторится — это не сервис. Без мониторинга вы просто запустили программу.

-Лимончелли

Мониторинг должен быть основан на SLA, указанном в документации на сервис (OpsDoc). Если у вас нет SLA, то как минимум нужна простая нотификация про доступность/недоступность сервиса.

Не забудьте обновить план нотификаций (Pager Playbook).

Подробнее:

  P2: p. 523, Chapter 22: Service Monitoring
  P2: p. 765, Chapter 31: Perception and Visibility / The System Status Web Page
  P2: p. 119, Chapter 5: Services / 5.1.13 Monitoring

13. Есть ли у вас график дежурств?

Есть ли у вас график дежурств или вы простофиля на вечном дежурстве?

График определяет когда и кто “носит пейджер” (или кто реагирует на внештатные ситуации).

Можно, в буквальном смысле, периодически “передавать пейджер” от одного человека к другому. Можно, чтобы у каждого был свой собственный пейджер, а ваша система мониторинга будет сама определять из расписания, кому слать сообщения. Лучше всего, когда есть общий почтовый адрес, который пересылает почту дежурному человеку, скрывая график дежурств от пользователей.

График дежурств может быть как простым, так и сложным. Когда внештатных ситуаций немного, имеет смысл использовать график одна неделя из n (для команды из n человек). Для более сложных ситуаций, имеет смысл разбивать день на три 8-часовые смены. Подход “вслед за солнцем” состоит в организации 8-часовых смен таким образом, чтобы дежурила та часть глобальной команды, у которой сейчас день. Можно дежурить неделю по 8 часов каждые n недель, если у вас в команде 3n человек. Вариации бесконечны.

Расписание приносит пользу многим людям: вам, вашим пользователям, руководству, и отделу кадров.

Оно приносит пользу вам, потому что позволяет строить планы вне работы. Я считаю, что правильный баланс между работой и личной жизнью имеет важнейшее значение. Если ваш баланс нарушен и нет графика дежурств, то это первое, что нужно исправлять.

График дежурств улучшает уровень обслуживания пользователей, потому что, вместо “панических попыток найти сисадмина”, у них есть простой и надежный способ сделать это.

Он приносит пользу руководству, потому что дает уверенность, что когда бы не случилась внештатная ситуация, кто-то всегда будет готов ею заняться.

Этот же график будет полезен и отделу кадров при расчете заработной платы и надбавок. Скрипт может генерировать отчет, основываясь на электронной версии графика, и отправлять его в отдел кадров.

Если вы думаете, что у вас нету графика, то этот график называется «24x7x365», а вы простофиля (и это не означает, что вы можете быть согласны с этим).

14. Используете ли вы отдельные системы для разработки, тестирования и производства?

Программисты ведут разработку на своих серверах, предназначенных для разработки. Когда они решают, что готовы, система собирается и устанавливается на тестовые сервера. Если отдел тестирования (QA, quality assurance) или отдел приема работы (UAT, User Acceptance Testing) подтверждает качество и приемлемость результата, та же сборка устанавливается на производственных серверах.

Это из базового курса по системному администрированию, правильно?

Почему же тогда, я постоянно встречаю администраторов, чье руководство не разрешает им организовать такую схему? Если ваше руководство говорит, что “иметь второй сервер — это слишком дорого”, они безнадежны. QA — не дорогой. Знаете, что дорого? Время простоя.

Эксперименты на производственной системе не просто опасны, они запрещены в среде, которая подчиняется SOX (Sarbanes-Oxley Act, закон США, регулирующий в т.ч. область управления и раскрытия информации - прим. пер.). Таким образом, использование производственных серверов для разработки попросту запрещено!

Тестовая система не обязательно должна быть такой же дорогой, как производственная. Она не должна быть такой же мощной, может иметь меньше оперативной памяти и более простые процессора. Это, вообще, может быть виртуальная машина, запущенная на сервере виртуализации, параллельно с другими виртуальными системами.

Конечно, если масштабируемость и скорость реакции системы являются ключевыми характеристиками, то, вероятно, ваша тестовая система должна будет ближе соответствовать производственной.

Подробнее:

  P2: p. 435, Chapter 18: Server Upgrades

15. Используется ли “канареечный процесс” при внесении изменений на большое количество машин?

Допустим вам нужно выкатить изменения на 500 машин. Быть может, это новое ядро. А может просто маленькое исправление.

Будете ли вы сразу выкатывать изменение на все 500 систем? Нет. Вы выкатите его на небольшое количество машин и посмотрите, вылезут ли какие-то проблемы. Нет проблем? Выкатываем на большее число машин. И так будем продолжать, шаг за шагом увеличивая число машин, на которое выкатываются изменения, пока не внесем изменения на все системы.

Машины, на которые выкатываются изменения вначале, называются “канарейки”.

Классический пример использования индикаторных животных — это канарейка в угольных шахтах. Вплоть до второй половины двадцатого века, шахтеры Англии и Америки брали с собой под землю канареек для раннего обнаружения ядовитых газов, включая метан и угарный газ. Более чувствительные птицы переставали петь или падали от газового отравления до шахтеров, давая им шанс выбраться из шахты или надеть защитные респираторы.

Источник: Wikipedia

Вот некоторые канареечные методы:

Один, несколько, много:

Внесите изменения в одну систему (например, в вашу личную), внесите изменения в несколько машин (например, ваших сотрудников), внесите изменения в большую группу машин (с каждым разом увеличивая группу). Любой сбой означает, что вы останавливаетесь, откатываете внесенные изменения и повторяете попытку только после того, как проблема решена.

Кластерная канарейка:

Обновляете 1 машину, потом 1% всех машин, потом 1 машину в секунду, пока все не обновятся (обычная практика в Google и других сайтах с большими кластерами)

Эта процедура может выполнятся вручную, но если вы используете систему управления конфигурацией, возможность использовать “канареечный процесс” должна быть в нее вшита.

Подробнее:

  P2: p. 56, Chapter 3: Workstations / 3.1.2.2 One, Some, Many

D. Подходы по автоматизации:

16. Используете ли вы инструменты управления конфигурацией, такие как cfengine/puppet/chef?

Система управления конфигурацией (Config Management, CM) — это инструмент, который координирует настройки машин. Он может управлять операционной системой, программным обеспечением, сервисами, или всем вместе.

До появления CM, администраторы вручную вносили изменения в системы. Если нужно было изменить настройку 100 систем, нужно было сделать это вручную. Те кто был поумнее, такую задачу автоматизировали.

Еще более умные сисадмины поняли, что было бы крайне удобно иметь общий инструмент для такой автоматизации. И они создали автоматизирующие системы, такие как track, cfengine, bcfg2, Puppet, Chef и другие.

Отличительной чертой систем управления конфигураций является то, что вы описываете конечный результат, который нужно получить, а система сама определяет, какие команды для этого нужно выполнить. Конечный результат описывается декларативными утверждениями, например «hostA является веб-сервером» или «на веб серверах установлены такие-то пакеты», а система управления конфигурацией переводит это в команды. Другим важным атрибутом CM является общий характер утверждений (“добавить выполнение скрипта foo.sh в cron”), которые автоматически преобразуются в подходящие для конкретной операционной системы настройки (например, foo.sh будет, в зависимости от ОС, добавлен либо в »/etc/crontab», либо в «/var/spool/cron»).

Использование CM позволяет, вместо ручного внесения изменений на каждой системе, изменить только конфигурационный файл и дать CM внести правки во все необходимые системы вместо вас.

Локальные правки на серверах — это не нормально. Каждый раз, когда вы создаете файл вроде /etc/crontab.bak или /etc/hosts.[сегодняшняя дата], это должно быть для вас индикатором того, что вы что-то делаете неправильно.

Управление конфигурацией — это конечная автоматизация. Из подмастерья чародея вы становитесь повелителем кукол. Это вам не фунт изюму.

17. Выполняются ли автоматизированные задачи под ролевыми учетными записями?

Мы часто создаем автоматизированные процедуры, которые запускаются в определенное время. Например, раз в ночь запускается скрипт, который валидирует базу данных.

В некоторых фирмах такие процессы запускаются от учетной записи одного из системных администраторов. Когда он покидает компанию, эти автоматизированные процессы умирают.

В хороших фирмах, такие скрипты запускаются от ролевой учетной записи, часто «root». Однако, безопаснее их выполнять от учетной записи с меньшими привилегиями.

18. Ваши автоматизированные задачи шлют почту только когда есть полезная информация?

Вы знаете историю о мальчике, который кричал “волк!”? А историю о cron-задаче, на которую не обращали внимания, потому что она дважды в день сыпала почтой и когда, наконец, она начала сообщать об ошибке, этого никто не заметил?

Мои правила простые:

  Если нужна немедленная реакция: выслать SMS или сообщение на пейджер.
  Если нужна реакция в течении суток: создать запрос в системе.
  Если сообщение информационное: записать в файл.
  Ничего не выводить, если нет полезной информации.

С помощью почты можно отправить и SMS, и создать тикет в системе запросов, но важно понимать, сама почта — это не лучший механизм оповещения. Вы можете быть включены в копию письма, которое отправляет SMS или создает тикет, но само письмо не должно быть первичным механизмом оповещения.

Наихудший вариант — это система, которая шлет журнальные сообщения всем системным администраторам по почте. Почтовая система — это не архив для логов.

Реальная история: мой друг, который живет в Нью-Йорке, работал в компании, где все автоматизированные задачи слали свой вывод почтой на адрес root@домен-компании. В свою очередь, «root» был списком рассылки, куда были включены все администраторы. Это генерировало бесконечный поток сообщений, а сисадмины в этой фирме буквально не могли прочесть почту, как бы они не фильтровали сообщения. В результате, для коммуникации администраторы использовали личные почтовые аккаунты, даже по рабочим вопросам. Что это была за компания? Большой провайдер сервиса электронной почты, который уже не существует (мне интересно, какие еще плохие решения способствовали развалу фирмы?).

E. Подходы по управлению парком машин:

*19. Есть ли у вас база данных всех машин?

Каждая фирма должна иметь информацию про свои системы. База данных должна хранить, как минимум, такую базовую информацию, как: ОС, ОЗУ, размер диска, IP-адрес, владелец, кого уведомлять о профилактических работах, и т.д.

Наличие базы данных машин, позволяет автоматизировать задачи, которые потенциально могут затрагивать все ваши системы. Такая база реализует ключевое требование для автоматизации многих задач: дает возможность выполнять команды только на машинах с определенной конфигурацией.

Информация о машинах должна собираться автоматически, хотя небольшие фирмы могут обойтись электронной таблицей или вики-страницей.

Инвентарная информация такого типа позволяет вам принимать решения, основываясь на данных, и помогает избежать проблем.

Я знаю одну историю, случившуюся в маленьком университете Нью-Джерси, который мог бы избежать больших проблем, если бы у них была хорошая система сбора инвентарной информации. Они попытались обновить Microsoft Office на всех своих компьютерах до последней версии. Исполнительный совет был преисполнен энтузиазмом: наконец наступит день, когда несовместимость перестанет превращать любою попытку взаимодействия в настоящее испытание. Кроме того, посмотрите на все эти новые возможности! Но как быстро этот энтузиазм сменился негодованием, когда проект провалился. Оказалось, что у трети компьютеров на кампусе не было достаточно памяти или дискового пространства. По всему университету было много случаев, когда обновление прошло неудачно, в результате чего сотрудники не могли делать свою работу. Исполнительный совет был не только разочарован, но и стал избрал принципиальную стратегию на избегание рисков. Пройдет еще не мало времени до следующей попытки провести обновления. Всего этого могло не случиться, если бы использовалась хорошая система сбора инвентарной информации. Она дала бы информацию, необходимую для правильного бюджетирования программы по обновлению программного обеспечения

20. Автоматизирован ли у вас процесс установки ОС?

Автоматизированная установка операционной системы быстрее, последовательнее и позволяет пользователям самим сделать часть ваших задач.

Автоматизированная установка ОС гарантирует, что все машины начинают свой жизненный цикл в одинаковом состоянии. Борьба с энтропией трудна, а если каждая машина сделана вручную, то она становится невозможной.

Ставя ОС вручную, вы тратите свое время впустую дважды: когда ставите систему и когда пытаетесь устранить проблему, которой бы не было, если бы у вас все машины были настроены одинаково.

Когда два человека устанавливают операционные системы вручную, половина из них будет настроена на так как нужно, причем вы не узнаете какая это половина. Оба могут утверждать, что использовали одну и ту же процедуру. Разведите их по двум разным комнатам и скажите чтобы они написали то, что они делали. Теперь покажите каждому из них, что написал другой. Ой, драка будет…

Пользователи воспринимают непоследовательность, как некомпетентность. Когда пользователю приходит новая система с всегда одинаковыми настройками, он знает, где поменять то, что ему не нравится. Когда же настройки постоянно разные, пользователь теряет доверие к системным администраторам. Что за тупицы ставят эти системы?

Если у вас есть возможность автоматически переустановить ОС, то она есть и у пользователей. Это минус одна задача для вас. Автоматизация, которая экономит вам время — это супер. Автоматизация, которая позволяет другим делать то, что им нужно — еще лучше.

Отсутствие возможности легко стереть и переустановить систему приводит к проблемам с безопасностью. Машина должна быть полностью стерта и переустановлена каждый раз, когда она меняет владельца. Когда этот процесс вызывает какие-либо сложности, возникает соблазн сэкономить время, пропустив этот шаг.

Подробнее:

  P2: p. 41, Chapter 3: Workstations
  P2: p. 32, Chapter 2: Climb Out of the Hole / 2.1.4 Start Every New Host in a Known State
  P2: p. 288, Chapter 11: Security Policy / Case Study: Security Though Good Infrastructure

*21. Можете ли вы автоматически обновлять ПО для всего парка машин?

Если установка операционных систем автоматизирована, все машины начинают свой жизненный цикл в одинаковом состоянии. Если автоматизирована и установка обновлений, то все машины остаются в одинаково-обновленном состоянии. Последовательность — вещь хорошая.

Обновления по безопасности крайне важны, поскольку от них зависит надежность ваших систем. Другие обновления тоже важны, потому что от них тоже зависит надежность ваших систем, но, кроме того, они приносят новые возможности вашим клиентам. Воздержание от установки обновлений — это как воздержание от проявления родительской любви. Кто вас растил?

Обновление приложений также критично, как и обновление операционных систем. Пользователи не делают различий между “ОС” и “приложением”, особенно если это приложение установлено у многих. Противные типы, которые пишут вредоносное ПО, такой разницы тоже не делают.

Я бы очень хотел, чтобы банки были обязаны публиковать описание своих процессов обновления ПО, так, чтобы я мог решить, где хранить деньги.

Обход всех машин, одна за другой, является альтернативой автоматизации установки обновлений. Этот подход раздражает пользователей, тратит их время впустую, да и ваше время тоже. А с распространением ноутбуков, думать, что вы сможете обойти все машины, стало наивным.

Обновление должно происходить незаметно для пользователя всегда, когда это возможно. Если требуется перезагрузка или другие действия, пользователи должны иметь возможность отложить обновление. Но здесь должно быть ограничение, например 2 недели, и это ограничение должно быть настраиваемым, чтобы срочные обновления по безопасности не откладывались на долго.

Подробнее:

  P2: p. 41, Chapter 3: Workstations / 3.1.2 Updating the System Software and Applications

22. Есть ли у вас политика обновления компьютеров?

Если у вас нет политики, регламентирующей когда обновляются компьютеры, они обновляться не будут.

[Под “компьютерами” я имею ввиду ноутбуки и рабочие машины людей, а не сервера.]

Обычно мы больше думаем о том, когда должны быть заменены устройства в серверных комнатах. Чтобы оставаться свежей, вашей компьютерной среде необходим повторяемый циклический процесс обновления. Без него, либо техника устаревает и становится неподдерживаемой, либо новая техника становится подтверждением статуса и приобретают политический окрас. При наличии хорошей политики, компьютерный парк остается современным и выгодным.

Определенная часть вашего парка должна быть старой — это просто экономически выгодно. Однако, слишком старые машины требуют больше затрат на поддержание, чем на замену. Поиск решения, как заставить работать новое ПО на слишком слабой машине — пустая трата времени, как и ожидание, пока медленный компьютер, наконец, завершит выполнять операцию. Очень старые машины оказывают негативный эффект как на производительность работы пользователей, так и на эффективность их тайм-менеджмента.

Компании часто попадают в такую ситуацию: стремясь “сэкономить деньги” они не обновляют компьютеры, но сотрудники с плохо работающими инструментами денег не экономят. А бывает, что компания просто не понимает, что компьютеры не вечны.

Вот простая политика для начала, если у вас ее еще нет: срок жизни компьютеров составляет 3 года. Годовой бюджет должен будет включать средства на замену ⅓ парка компьютеров. В первый день каждого квартала должно быть заказано достаточное количество компьютеров для замены 8-9% самых старых машин.

Финансовым директорам нравиться такой подход, потому что им нравится предсказуемость. В одной компании финансовый директор был очень доволен, когда я дал ему возможность решать, когда будет происходить обновление техники. Мы договорились, что ¼ часть всех обновлений должна происходить за квартал, а он решал в какой именно месяц это произойдет. Он даже мог разбить квартальное обновление на несколько частей и закупать их в разные месяцы.

Вместо того, чтобы периодически бегать к финансовому директору и выпрашивать новые компьютеры, мы организовали регулярный и спланированный процесс. Сделали жизнь проще для всех.

Совет профессионалов: в некоторых компаниях срок жизни сервера отличается: они спроектированы, чтобы служить дольше и потому их жизнь длится 4 года. С другой стороны, их цена амортизируется на всех пользователей и потому срок жизни в 2 года может быть вполне оправданным.

Подробнее:

  P2: p. 41, Chapter 3: Workstations

F. Подходы серии “Мы согласны, что техника ломается”:

*23. Будут ли работать ваши сервера, если на них откажет один из дисков?

Раньше как было: если в компьютере что-то умирало, то происходил простой в работе. В сущности, выход из строя одного компонента был эквивалентен простою. Исчезала надежда что-то сделать в этот день и плакали ваши планы съездить на корпоративный пикник. Один отказавший диск рушил планы на целый день, почти как атомная война.

Сейчас все изменилось. Мы строим “живучие системы”. Диск может отказать, но простоя не будет, если мы используем зеркалирование дисков. Простой возникнет только если диск с зеркальной копией тоже выйдет из строя. По статистике, у нас есть часы и даже дни, чтобы заменить отказавший диск, прежде чем случится простой, видимый для пользователей. Гораздо лучше потратить свое время на то, чтобы быстренько заменить диск, чем провести целый день за восстановлением данных с лент.

Такой подход отделяет “сбой компонента” от “простоя”. Жизнь становится лучше. Раньше системы RAID были дорогими и редкими, что-то вроде роскоши для богатых. Сейчас они стали распространенными, недорогими, а часто и вообще бесплатными (программный вариант). Я сказал распространенными? Хотел сказать обязательными. День, потраченный на восстановление данных с лент, это не просто знак плохого планирования, это знак плохого тайм-менеджмента. Утешение пользователя, потерявшего год, месяц или даже несколько часов работы — это пустая трата времени, а не героизм. Это плохое системное администрирование. И давайте не забывать еще большее расточительство рабочего времени: времени ваших пользователей, которые ждут, пока их данные будут восстановлены с резервной ленты. Отказы дисков — не редкость. Зачем тогда строить системы, считая что диски практически безотказны?

Среднее время наработки на отказ для серверного диска равно примерно 1,5 млн часов. Если у вас 1 тыс. дисков, отказ будет случатся раз в два месяца, если у вас 10 тыс. дисков — то каждую неделю. Вы действительно планируете так часто тратить по дню, восстанавливая данные с лент?

Мой подход следующий: для всех маленьких серверов загрузочный диск должен быть зазеркалирован, и любой диск с пользовательскими данными, должен быть в RAID1 или выше.

Загрузочный диск: я рекомендую зеркалировать загрузочный диск на всех серверах, потому что обычно невозможно полностью восстановить сервер с нуля. На загрузочных дисках часто собирается всевозможное “наследие”: за годы работы ставятся разные пакеты. В глубоких закутках файловой системы могут хранится недокументированные драйвера, патчи и прочие “костыли”. Конфигурация системы часто бывает больше историей компании, нежели продуманным и спланированным дизайном. В идеальном мире, все было бы по-другому: каждую систему можно было бы воспроизвести с помощью автоматизированной системы. Увы, это та цель, который мы еще не достигли. Основным исключением из этого остаются кластеры с гомогенными системами, как, например, высокопроизводительные кластеры (HPC), или Google и Yahoo!. Увы, дорогой читатель, я уверен, что это не ваша ситуация. Вообще говоря, я уверен, что даже в Google и Yahoo! виндовс-сервер, на котором крутится система управления электронными замками дверей здания, представляет собой крайний случай сервера, где требуется зеркалирование загрузочного диска.

Да, вы, вероятно, сможете восстановить такой сервер за день, если повезет, но RAID1-контроллер стоит меньше, чем день работы администратора с минимальной зарплатой.

Пользовательские данные: я рекомендую RAID1 или выше для пользовательских данных потому что это так дешево, что его отсутствие это просто стыд. Кстати… вы же знаете, что для дисков, размером от 2Т, RAID6 — это минимум, правда? Использование RAID5 для таких дисков отдает профессиональной халатностью. Еще раз: для таких дисков RAID6 или RAID10 — это минимум. По крайней мере пока, но тут мы уходим в сторону.

Исключением из всего вышесказанного является любая система, которая продолжит предоставлять сервис при сбое отдельного компонента, будь то диск, машина или центр обработки данных. Плюс данные, которые могут быть восстановлены в пределах SLA. Вот некоторые примеры:

Использование модных избыточных файловых систем, таких как Google File System (GFS). GFS хранит информацию как минимум в 3-х разных местах. Система GPFS Native RAID (GNR) фирмы IBM работает аналогичным способом.
"Пробное и временное", когда пользователи знают, что этот сервис может исчезнуть в любой момент.
Видео, либо другая информация только для чтения, которая может быть восстановлена с оригинального носителя в случае утраты.
Копия только для чтения информации, хранящейся в другом месте. Хотя, если вы реплицируете эту информацию из соображений увеличения скорости доступа, RAID5 может еще больше ее увеличить благодаря большему количеству шпинделей.
Легкозаменимые машины. Например, веб-сервер со статическим контентом или вторичный кэшируюший DNS сервер могут быстро и автоматически перегенерированы. Если у вас используются сотни серверов такого типа, экономия на RAID-контроллерах может быть существенной.

Подробнее:

  P2: p. 83, Chapter 4: Servers / Mirror Boot Disks

24. Используется ли схема N+1 в ядре вашей сети?

Сетевой сбой, который влияет на одного сотрудника, это стыд. Сбой, влияющий на много людей, просто неприемлем. Точно также, как и избыточные диски, резервные соединения стали сейчас обязательными.

Да, одно соединение от рабочего компьютера до коммутатора все еще норма, но дальше первого коммутатора все должно быть избыточно по схеме N+1. Как минимум, все магистрали должны быть с двойным подключением. В идеале — отказ любого подключения, сетевой карты, маршрутизатора или коммутатора не должен приводить к потере связности.

Локальные сети обычно проектируются следующим образом: офисные ноутбуки/компьютеры подключаются в настенную розетку. Эти розетки подключены к “коммутаторам доступа” с большим количеством портов. В свою очередь, коммутаторы доступа магистралями подключаются к иерархии центральных коммутаторов, которые обеспечивают доставку пакетов в нужное место, возможно за пределы локальной сети (в другие офисы или в Интернет).

Я использую простое правило: ядро сети должно быть избыточным. Раньше это было роскошью для богатых, теперь это стало необходимым требованием.

Если ваша сеть не использует этот принцип, то вы живете в том времени, когда компьютеры были полезными без сети.

Исключение: маленькие сети в которых нет ядра. И даже в таком случае, магистрали должны быть избыточными, а для каждого типа коммутатора должен быть запасной комплект.

Подробнее:

  P2: p. 187, Chapter 7: Networks

*25. Автоматизировано ли ваша процедура резервного копирования?

Этот вопрос предполагает, что вы делаете резервные копии. Вы ведь делаете их, правда?

Вот четыре причины, почему вам нужны бекапы: (1) Ой, я удалил файл. (2) Опа, железо умерло. (3) Ой-ой-ой, здание сгорело. (4) Архивы. Каждая из этих причин может требовать отдельного похода.

Ситуация (1) решается с помощью снепшотов в краткосрочной перспективе, но не в долгосрочной. Иногда, файл, который нужно восстановить, был удален давно, и тут простые снепшоты не помогут, как и RAID. RAID — это не механизм резервного копирования. Если кто-то удалит файл по ошибке, RAID послушно среплицирует эту ошибку на все зеркала. И у вас получится избыточный массив неправильных данных.

Ситуация (2) вроде бы решается с помощью RAID, но помните, что двойной сбой дисков полностью разрушит RAID1 или RAID5. RAID10 и RAID6 будут разрушены при тройном сбое. И такие вещи случаются. Всего один неуклюжий электрик вас отделяет от сгорания всех дисков одновременно. Серьезно.

Ситуация (3) часто называется «аварийным восстановлением». Единственная надежда — резервные копии либо на дисках, либо на лентах, хранящиеся вне здания.

Ситуация (4) возникает вследствие необходимости соответствовать неким нормам. Технологически это реализуется аналогичным Ситуации 3 образом, но срок хранения информации другой. Если такое резервирование требуется какому-то отделу для соответствия нормам, он должен оплачивать стоимость носителей.

Каждая из перечисленных ситуаций требует автоматизированного решения. Вряд ли вы хотите рассказывать начальству о том, что данные утеряны, потому что “я был в отпуске” или “забыл поменять ленты”, после того, как сгорел ваш офис.

Наконец, автоматизация важна, потому что супернавороченная ленточная библиотека все-равно стоит дешевле, чем вы. Да, можно нанять клерка, чтобы он постоянно менял ленты. А можете купить библиотеку, с достаточным на месяц объемом лент. Библиотека выйдет дешевле. И она должна вмещать в два раза больше лент, чем нужно на ваш самый длинный отпуск.

Подробнее:

  P2: p. 619, Chapter 26: Backup and Restore

*26. Проверяете ли вы периодически свой план аварийного восстановления?

В предыдущем разделе мы немного покривили душой. Там были указаны не 4 причины почему нужно делать резервные копии, а 4 причины почему надо восстанавливать данные.

Людям нет дела до бекапов, им важно иметь возможность восстановить данные. Если вы придумаете, как можно восстанавливать данные, не делая предварительно резервных копий, я пролоббирую в Нобелевском комитете создание номинации для системных администраторов, и вы будете первым, кто получит приз по ней.

Если резервная копия не проверяется, неизвестно действительна ли она. Плохи те системы резервного копирования, которые основаны на вере. Вера придает нам силы, но это не ИТ-стратегия.

Полный тест копии включает симуляцию полного краха и полного восстановления.

Вы не узнаете, сколько понадобиться времени на восстановление, пока его не проведете. Восстановление с лент часто занимает в 10 раз больше времени, чем сам бекап. Если полное резервное копирование вашей системы расчета заработной платы занимает 8 часов, нужно быть готовым, что ее восстановление с нуля займет 80 часов. А это больше трех полных суток.

Если вы вообще не проверяете свои резервные копии, то простенькое тестирование уже лучше, чем ничего. Напишите маленький скрипт, который будет выбирать случайный сервер, на нем — случайный диск, а на диске — случайный файл. Потом скрипт должен создавать тикет на восстановление этого файла (в новое место), каким он был 6 недель назад. Настройте автоматическое выполнение этого скрипта раз в неделю и с большой вероятностью он найдет сервер или диск, который отсутствует в системе резервного копирования. Да, и если вы думаете, что это тестовое восстановление будет занимать много времени, то есть небольшой секрет: оно вообще не будет занимать ваше время, если его выполнит ваш коллега. Пусть ваш скрипт генерирует тикеты с разнообразными описаниями, и тогда коллеги не узнают, что это было просто учебная тревога.

Можно сделать еще один шаг: спланируйте “веселый день”, когда реально проверится аварийное восстановление. Представьте, что некоторые люди “ушли в небытие” и проверьте, что остальные знают, как бороться с отказом сервисов. Напишите описания тестов, которые нужно выполнить. Потом спровоцируйте реальный отказ (выдерните кабель питания или сетевое подключение), либо сымитируйте его, а “человек из небытия” проконтролирует действия по восстановлению. “Так, допустим, вы получили вот такое сообщение. Расскажите мне команды и действия, которые вы будете выполнять”. Еще один способ спровоцировать отказ, это дать возможность генеральному директору выйти в серверную и отключить любой кабель на его усмотрение.

Подробнее:

  P2: p. 261, Chapter 10: Disaster Recovery and Data Integrity
  P2: p. 473, Chapter 20: Maintenance Windows

27. Есть ли в вашем ЦОД системы удаленного управления питанием и доступа к консолям?

Здесь мало что нужно объяснять. Коммутаторы удаленного доступа к консоли (IP-based KVM switches) недороги и они встроены в хорошие сервера. Удаленное управление питанием перестает быть роскошью, если компьютер находится более чем в нескольких километрах от вас.

Исключение из этого правила, это грид-системы (grid computing systems) с сотнями и тысячами идентичных машин. Если одна из них сбоит, другая забирает на себя ее функции.

Подробнее:

  P2: p. 261, Chapter 10: Disaster Recovery and Data Integrity

G. Подходы к безопасности:

*28. Ваши сервера/ноутбуки/компьютеры защищены автоматически обновляемым антивирусным ПО?

Вирусы и вредоносное ПО давно уже часть нашего мира. Если вы думаете, что плохие вещи не случаются с хорошими людьми, то тогда мы все плохие люди. Каждый компьютер теперь требует ПО для борьбы с вредоносным ПО.

Каждое вредоносное действие означает работу для вас: чистку машины, восстановление данных, утешение пользователей, потерявших результаты работы. Пустая трата времени для вас, непростительный сбой для ваших пользователей, и плохой тайм-менеджмент.

Противовирусному ПО требуется периодическое обновление. Некоторые из таких программ выводят большое окно, где написано “Есть обновления! Хотите становить?”. Это очень важное окно, потому что в нем есть лого программы. Пользователи запоминают его и потом могут рекомендовать друзьям. Когда много людей знает производителя, это положительно сказывается на цене его акций. И не важно, что 9 раз из 10 пользователь в таком окне нажимает “нет”. Программы, которые молча обновляются, без анимированных информационных окон, теряют эту замечательную возможность. Это очень безответственно со стороны компании не заботиться о своих акционерах.

Если кто-то все-таки сомневается — это сарказм.

Существует большое количество антивирусного ПО. То, которым вы собираетесь пользоваться, должно обновляться молча.

Обеспечить соблюдение политики безопасности — ваша задача, а обновление антивирусного ПО — часть этой политики. Делегирование этой ответственности пользователям неправильно, а, возможно, и неэтично. Вы же не спрашиваете пешеходов: “Мне нажать на тормоза, чтобы вас не задавить?”. Точно также вы не должны давать пользователям возможность отказываться от обновлений. Да, когда-то у нас были модемы на 300 бод и загрузка вирусных баз заняла бы 30 минут. Только вы еще тогда не родились и потому эта отговорка не принимается. А если вы в то время уже работали (как я), то уже много чего повидали, чтобы знать что к чему.

По аналогичным причинам, возможность отключить антивирусное ПО не должна быть легкодоступной пользователям, иначе они будут его отключать по самым нелепым причинам. Обычная причина — чтобы повысить скорость работы. У меня был пользователь, который отключил антивирус, потому что “он привлекал вирусы”. Он объяснял это так: “Понимаете, когда он запущен, постоянно появляются предупреждения о вирусах. Как только я его выключаю — сообщения пропадают”. Да, люди с таким искривленным понятием о причинно-следственной связи существуют.

Раньше антивирусное ПО было “полезно иметь”, но теперь это превратилось в безусловное требование. Вот мои правила:

1) Антивирусное ПО должно быть запущено на всех машинах, включая любой сервер, где находятся пользовательские данные: домашние каталоги, файловые шары, содержимое веб-сайтов, FTP-сервера, и т.д.

2) Сканеры должны обновляться автоматически и скрытно. Никаких подтверждений от пользователей.

3) Должен быть механизм, позволяющий определить, что сканер отключен. Например, центральный сервер, где все сканеры должны регистрироваться. Тогда вы сможете видеть, какие машины больше не обновляются.

4) Почта должна сканироваться на сервере, не на клиенте (на клиенте тоже может, но в дополнение к серверной проверке). Сообщения с вирусами должны уничтожаться, спам — помещаться в карантин. Вы не можете полагаться, что каждая личная машина будет иметь единый, высококачественный и обновленный фильтр, сравнимый с серверным. Остановите проблему до того, как она доберется до клиента.

Подробнее:

  P2: p. 284, Chapter 11: Security Policy / State of Security
  Blog post: EverythingSysadmin Blog: Not being attacked? Your network must be down.
  Blog post: EverythingSysadmin Blog: Yes, malware scanners on your servers too!

*29. Есть ли у вас политика безопасности в письменном виде?

Просмотрите существующие политики, чтобы набраться идей для своей. Библиотека примеров есть на сайте SANS:

http://www.sans.org/security-resources/policies/

Очень важно иметь политику безопасности в письменном виде до того, как ее реализовывать на практике.

Подробнее:

  P2: p. 293, Chapter 11: Security Policy
  P2: p. 293, Chapter 11: Security Policy / 11.1.2 Document the Company's Security Policy
  P2: p. 293, Chapter 11: Security Policy / 11.1.3.5 Authorization Matrix

30. Проводите ли вы регулярный аудит безопасности?

Здесь мало что нужно объяснять. Если вы не проверяете свою безопасность, вы не знаете насколько вы уязвимы.

Подробнее:

  P2: p. 298, Chapter 11: Security Policy / 11.1.3.7 Internal Audits
  P2: p. 308, Chapter 11: Security Policy / 11.1.4.3 External Audits

31. Можете ли вы отключить учетную запись пользователя во всех системах за 1 час?

Ответ на этот вопрос говорит о вашей команде и среде намного больше, чем может показаться на первый взгляд. Он говорит, используете ли вы централизованную систему управления учетными записями.

Наличие единой системы авторизации для всех систем уже перестало быть “приятным дополнением” и стало обязательным. Если вы думаете, что оно вам не нужно, пока вы не вырастете, то вскоре обнаружите, что времени на запуск единой системы авторизации, в период интенсивного роста, нету.

Зарекомендовавшим себя подходом является использование систем управления жизненным циклом учетных записей. Использовании таких систем позволяет управлять созданием и модификацией учетных записей начиная с момента подготовки к приему человека на работу, в течении жизненного цикла учетной записи, до завершения сотрудничества и после этого. Что если у пользователя поменяется имя? Что если кто-то возвращается в компанию? А если человек возвратится в компанию и у него изменилось имя? Есть множество подобных “нетипичных случаев” и система управления должна с ними справляться.

Подробнее:

  P2: p. 223, Chapter 8: Namespaces
  P2: p. 899, Chapter 36: Firing System Administrators

32. Можете ли вы сменить все привилегированные (root) пароли за 1 час?

Здесь тоже ответ говорит о большем, чем непосредственно спрашивается. Он говорит насколько хорошо контролируется административный доступ.

Если у вас нет такой возможности, создайте список на вики со всеми местами, где нужно сменить пароль. После этого, смените везде пароль по списку, добавляя по ходу пропущенные или забытые системы. Для сложных систем, укажите конкретные команды для смены пароля или опишите процесс смены пароля.

Если такая возможность у вас есть, создайте страничку на вики с описанием, как активировать этот процесс (и укажите все исключения, которые требуют смены пароля вручную).

Подробнее:

  P2: p. 223, Chapter 8: Namespaces
  P2: p. 899, Chapter 36: Firing System Administrators

Thanks to all the people that gave feedback on drafts: Strata Chalup, Sabrina Farmer, Aeleen Frisch, Doug Hughes, Duncan Hutty, Ski Kacoroski, Christina Lear, Edward Marczak, Troy Mckee, Adam Moskowitz, Tanya Reilly, Matt Simmons, Josh Simon, Nicole Forsgren Velasquez. (Especially Aeleen and Ski for helping reorganize the list and Josh and Nichole for extensive editing help.)

Since publication, helpful suggestions have come from: Jay Ashworth, Duncan Hutty.

Revision History:

2011-07-25: First public release.

2011-07-25: Many small updates.

2011-11-06: Editing and updates.

Негласные истины управления гиками

anonymous@undisclosed.example.com (Anonymous) — Tue, 09 May 2017 15:34:00 +0000

Негласные истины управления гиками

Все статьи, книги и заметки, написанные выдающимися специалистами по менеджменту об управлении айтишниками, можно свести к двум предложениям: «Гики умны и креативны, но при этом они эгоцентричны, замкнуты, отрицают руководство и правила бизнеса, склонны быть жертвой, упрямы и тщеславны. Чтобы преодолеть эти неуправляемые поведенческие недостатки, вы должны делать первое, второе и третье».

«Первое, второе и третье» отличается и, как правило, противоречит друг другу от одного специалиста к другому, но снисходительный стереотип остается неизменным. Я не вполне уверен, что в этом есть какая-то польза. Поэтому, позвольте мне взять уже знакомую кисть и нарисовать новый портрет айтишников, обитающих где-то в глубине вашей организации.

В своей карьере мне приходилось оказывать немало консультационных услуг по аварийному восстановлению, и я имел дело с десятками организаций, переживающих свои не лучшие времена, когда высказывались довольно-таки неприкрытые суждения. Я слышал и все вышеупомянутые стереотипы, и стереотипы намного хуже, и кое-какие гневные высказывания. Чем в более скверной форме находится организация, тем чаще вы слышите, разбрасываемые кругом стереотипы. Однако мой личный опыт работы с ИТ-группами всегда был достаточно неплохим, я работал с айтишниками, к которым все эти негативные стереотипы просто неприменимы. Я всегда относил провалы ИТ-групп на счет неудачного найма и тонкого баланса этих самых гиковских стереотипов.

Тем не менее, в последнее время, я осознал, что идеально здоровые ИТ-группы с серьезными и уравновешенными профессионалами в соответствующих условиях могут и будут, тихо и не спеша, скатываться к такому поведению, которое порождает эти стереотипы. Оказывается, что стереотипными являются именно условия, а айтишники лишь логически на них реагируют. Другими словами, организации активно добиваются этого стереотипного негативного поведения.

Понимание того, почему айтишники так ведут себя, сделает работу с ними, среди них и в качестве одного из них, семой легкой работой в мире.

Все дело в уважении

Немногие это замечают, но уважение для ИТ-групп — это валюта их царства. Айтишники не разбрасываются этой валютой. Тот, кто, по их мнению, не стоит уважения, взамен будет получать профессиональную этику, дружеские манеры или признание авторитета. Получить уважение это не значит быть начальником, и никак не связано с тем, чтобы быть привлекательным или общительным, правильно разговаривать, есть или пахнуть, либо делать что-то еще, непосредственно несвязанное с работой. Доля уважения, получаемая кем-либо от айтишника, зависит от того, насколько терпим этот человек, когда дело доходит до непосредственного выполнения задач, а также насколько элегантны и практичны предлагаемые им решения. Айтишники всегда и непременно будут молча самоорганизовываться вокруг тех, кто облегчает работу, и чураться тех, кто ее усложняет, независимо от занимаемой должности.

Саморегулирующееся поведение возникает в мире айтишников естественным образом, потому что он населен людьми с навыками креативного анализа и упорядоченной аргументации. Врачи — наиболее близкая к ним профессия. Пусть в медицине ставки выше, но в обеих сферах требуется профессиональная компетенция, которую нельзя симулировать, и профессионализм, который могут оценить лишь квалифицированные коллеги. Думаю, что все хорошие айтишники на планете поклоняются доктору Хаусу (за вычетом его пристрастий).

Тогда как всем хотелось бы работать на милого человека, который всегда прав, айтишники предпочтут работать на гада, который всегда прав, чем на душку, который всегда не прав. Неправота создает ненужную работу, невыносимые ситуации и крупные провалы. Неправота зла, и должна быть разгромлена. Способность мыслить логически бьет все остальные профессиональные факторы, точка.

Фундаментальное уважение (снизу-вверх) — это не только единый крупнейший определяющий фактор, влияющий на успех ИТ-команды, но и самый игнорируемый фактор. Считаю, что можно предсказать успешность ИТ-группы, лишь оценив уровень взаимного уважения в ней.

Элементы стереотипов

Эго — по аналогии с хорошими врачами, айтишники понимают, что правильное проецирование своего эго порождает доверие и снижает сомнения. Так как образование айтишников не делает упор на работе с людьми, то в этой области всегда есть шероховатости. Эго в ИТ состоит из комбинации необходимой доли уверенности с не такой уж малой долей скептицизма. Дело не в том, чтобы быть правым ради того, чтобы быть правым, но быть правым ради того, чтобы сэкономить время, усилия и деньги, а также сохранить авторитет. ИТ — командная игра, поэтому правота или неправота одного члена команды немало влияет на других ее членом. В отличие от других отраслей, в ИТ коллеги могут значительно повлиять на карьеры членов всей команды. Безошибочность приносит уважение, уважение создает хорошие команды, а хорошие команды создают доверие и поддерживают авторитет посредством здорового проецирования своего эго. Сильные ИТ-группы рассматривают безошибочность как добродетель, а уверенность — как механизм ее подачи. Кроткие ИТ-группы, забитые противоречивыми правилами и отсутствием структурной опоры, просто не в состоянии добиваться перемен и продуктивности, на каждом шагу подкашиваемые клиентами, руководством или и теми и другими.

Менталитет жертвы — айтишники хорошо чувствуют логику, за это вы им и платите. Когда что-то не клеится, они склонны выражать свое мнение по этому поводу, и уровень реакции будет пропорционален абсурдности события. Чем больше бессмысленных вещей происходит, тем циничнее будут вести себя айтишники. Политика стандартной организации часто грешит этим, поэтому айтишников часто воспринимают как нытиков или людей с менталитетом жертвы. Руководство делает большую ошибку, полагая, что эту черту нужно искоренять. Как правило, айтишники жалуются на отсутствие логики и, как правило, тем, кого уважают. Если вы пренебрежительно относитесь к их жалобам, не осознаете нелогичность событий или ведете себя обманчиво, айтишники, скорее всего, прекратят вам жаловаться. Вы можете ошибочно принять это за поведенческое улучшение, когда на самом деле это демонстрация неуважения. Это значит, что с вами больше не стоит разговаривать, а это ведет к нарушению субординации.

Нарушение субординации — здесь не все так просто. Хорошие айтишники не столь анти-бюрократичны, как может показаться внешнему наблюдателю. Они анти-идиотичны. И разница здесь и субъективна и тонка. Хорошим айтишникам, требуется от них это или нет, приходиться работать и принимать решения практически без надзора сверху. Поэтому, когда нет жестких правил, а те, что есть — логичны, при этом руководство ориентируется на результат, оказывая поддержку и помощь, айтишники лояльны, открыты, заинтересованы и крайне общительны. Своевольный менеджмент или микроменеджмент, нелогичные решения, противоречивые правила, создание ненужной работы и запретительство повлекут за собой молчаливое, подрывное, практически злобное отношение в остальном отличных айтишников. Интересно, что ИТ-группы в таком режиме не распадаются. Снаружи все выглядит нормально, и работа по-прежнему выполняется. Но внутри, ИТ-группа или ее части, могут полностью отрезать себя от заданной управленческой структуры. Они могут работать над крупными проектами или управлять группой, полностью скрываясь в тени, при этом отвлекая внимание руководителей на различные мелочи. Они считают, что защищают не только организацию, но и свой авторитет, и в этом они, зачастую, правы.

Тщеславие — айтишники предпочтут принять хорошее решение, чем поставить его себе в заслугу. Единственное, что может заставить их искать признания, это опасность того, что член группы или руководства, угрожающий процессу, может получить признание за выполненную работу вместо них. Это оскорбительно. Если в вашей ИТ-группе много тщеславных, значит, существуют большие проблемы, из-за которых это происходит.

Замкнутость — это правда, что многие айтишники не имеют навыков общения, но это не значит, что они замкнуты. В общем и целом, им есть много, что сказать. Если вы хотите, чтобы айтишники принимали больше участия, вам следует разобраться с проблемами, описанными выше, а затем научить ваших сотрудников, как вести себя с айтишниками. Пользователям нужно кое-что напомнить, а именно:

Айтишники хотят мне помочь.
Я должен быть непредвзятым.
Айтишники — не мои личные консультанты, а мой рабочий компьютер — не мой личный компьютер.
У айтишников есть своя жизнь и свои интересы.

Как и все, айтишники общаются с теми, кто их уважает. Они перестанут участвовать в пикниках работников компании, если эти пикники превращаются в повод для всех рассказать о своих компьютерных проблемах, о которых они не удосужились сообщить раньше.

Как мы создаем стереотипы

Руководители часто не осознают того, что все принимаемые решения, которые отражаются на айтишниках, это технические решения. Не только некоторые решения, и не только детали решений, а все решения без исключения.

В ИТ невозможно отделить технические аспекты от деловых аспектов. Это одно и то же, они ограничиваются друг другом, при этом и то и другое ограничивается креативностью. Креативность — самый ценный актив ИТ-группы, и если его не поддерживать, это может стоить организации буквально миллионы долларов.

Большинство айтишников работают в организациях, не связанных с ИТ. Основная задача любой ИТ-группы — научить людей работать. Это может прозвучать авторитарно, но это не так. На фундаментальном уровне функция ИТ заключается в создании, поддержке и модернизации интегрированных систем, внутри которых решаются поставленные задачи. Вы можете не рассматривать веб-сервер в качестве интегрированной системы для решения задач, но, тем не менее, он автоматизирует процесс рекламы, продаж, информирования и приема клиентов, и если бы его не существовало, все эти задачи приходилось бы решать по-другому. Айтишники буквально учат и переучивают мир работать. Вот в чем их задача.

Когда вы осознаете задачу ИТ, то нетрудно понять, почему сослуживцы и руководители подвергаются столь жесткой критике согласно своим способностям способствовать этому процессу. Если кого-то приходится постоянно учить компьютерной грамотности, как только перед ним встает новая задача, то значит, он не может вносить свой вклад на самом фундаментальном уровне. Одно дело, когда такое исходит от сослуживца, и другое, когда люди, представляющие ИТ, не совсем понимают, как работает эта технология, и не могут донести это так, как подобает ИТ-группе, не могут поддерживать стабильность, приписывают себе работу членов группы, и т.д. Перед группой предстает огромная моральная проблема. Руководители ожидают компетентных советов от ведущего айтишника, но у них нет возможностей понять, получают ли они их. Вот в этом и кроется вся проблема.

Айтишники понимают, когда такое происходит, но выясняется, что к этому невозможно привлечь внимание. Когда их работе препятствует такая проблема, они выработают стратегию и поведение, помогающие ее обойти. Это неустойчивое состояние, но прежде чем все окончательно обрушится, могут пройти дни, месяцы или даже годы.

Что делать

Поэтому, если вы хотите получить действительно довольную, здоровую и ценную ИТ-группу, я могу порекомендовать только одно: проявляйте интерес. Айтишники будут работать до потери пульса для людей, которых они уважают, поэтому вы должны дать им для этого все причины.

Начать можно еще в процессе найма. Нанимая айтишника, представьте, что нанимаете доктора. А нанимая руководителя отдела ИТ, подумайте о найме главврача. У главврача должно быть несколько квалификаций, но первое и самое главное — он должен быть практикующим врачом. Кто решает, является ли врач врачом? Другие врачи! Так что если ваша ИТ-группа не присутствует за столом при найме своих начальников или коллег, то это уже наносит вред всему процессу.

Отдавайте предпочтение технической компетенции и лидерским навыкам. Стандартные управленческие процессы практически бесполезны в ИТ-группе. Как говорилось ранее, если вы удачно наняли рядовых членов группы, то они уже знают, как управлять процессом. В отличие от многих отраслей, в большинстве ИТ-групп борьба идет не за то, как избежать работы, а за то, как выполнить задачу. Ради выполнения задачи айтишники могут сами себя организовать, дезорганизовать и перевернуть с ног на голову. Замысловатый, технически слабый коротышка, занимающийся микро-менеджментом, каким бы отполированным он не был, заброшенный в этот котел только для управления, получит от профессиональной ИТ-группы такую же реакцию, какую получит пятилетний ребенок от взрослого, которого он дергает за штанину.

Айтишникам нужен менеджер, который выслушает и даст общее направление. Лидерские качества и техническая компетентность должны присутствовать у каждого члена команды. Если вам нужен человек, который будет отслеживать ход проектов, составлять отчеты и работать с заказчиками, вы можете за гораздо меньшую зарплату нанять ассистентов.

Что касается проверок продуктивности, годовые обзоры бессмысленны без всесторонней (или 360-градусной) оценки. Такие вещи требуют больше времени, чем простой нисходящий обзор, но это время будет потрачено с пользой. Если вы внимательно прочли все, что я писал о поведении и организации ИТ-групп, то вы сможете посмотреть на свою ИТ-группу в ином свете, когда будете читать результаты ее всесторонней оценки.

И убедитесь, что все ваши менеджеры являются практикующими и обучаемыми. На таких должностях очень легко скользить по кривой, но, как и с врачами, практика и поддержка навыков — это единственный способ оставаться компетентным. В ИТ уважение и некомпетентность разделяются лишь сроком от шести месяцев до года.

И наконец, у руководителей в распоряжении должно быть несколько путей подхода к ИТ-команде. Если команда начинает фальшивить, то стоит разобраться и выяснить причины. Но вы никогда даже не узнаете, что такое происходит, если вашим единственным источником информации будет руководитель отдела ИТ. Периодически приглашайте ключевых айтишников на совещания, чтобы они могли понаблюдать за общими проблемами организации, даже если речь идет о вещах, не относящихся к миру ИТ, хотя бы для того, чтобы воспользоваться их высокочувствительными датчиками бреда. Хороший айтишник обучен выполнять поставленные задачи, и его навыки не обязательно ограничиваются только компьютерами. Кстати, из всех, кого я знаю, лучшие деловые решения принимают именно айтишники, при этом, даже не являясь менеджерами.

Как я говорил в самом начале, все дело в уважении. Если вам удастся выявить и поддержать тех людей и те процессы, которые приносят подлинное уважение айтишников, у вас будет великолепная ИТ-команда. Неподдельная заинтересованность в том, чтобы помочь айтишникам помочь вам — вот, пожалуй, самый умный ход для организации. Так вы получите довольных, абсолютно негиковых гиков.

ит, управление гиками

Практика выведения отдела ИТ из кризисного состояния

anonymous@undisclosed.example.com (Anonymous) — Tue, 09 May 2017 15:34:00 +0000

Практика выведения отдела ИТ из кризисного состояния

Источник: http://habrahabr.ru/post/143976/

Немного вводных данных

Компания, в которую я пришёл работать на должность начальника отдела информационных технологий, занимается разработкой и внедрением учётных систем. В то время было 3 крупных проекта информатизации и десяток компаний-абонентов ИТ аутсорсинга в комплекте с сопровождением учётных систем. Количество обслуживаемой техники около 250 компьютеров и серверов.

Немного о персонале.

Отдел состоял из четырёх человек, двое из них работали в компании первый месяц — это были 2 студента без спец. навыков, пришедшие на первую работу, ещё один человек, как мне сказали, «его уровень выше чем у остальных», как выяснилось позже, эта точка зрения была субъективной, ну и четвёртый человек — это сотрудник, находящийся при клиенте, т.е. привлекать к проектом не представлялось возможным.

Особое впечатление у меня осталось от первого взгляда на помещение в котором располагались 3 человека и начальник отдела. Это была небольшая комната, для того, чтобы пересечь её по диагонали, от входа к рабочему месту начальника отдела, в дальнем левом углу комнаты, нужно было 2-3 раза переступить через коробку с серверов HP, бесперебойник или системный блок.

Прежний руководитель не нашёл другого места для размещения проектных материалов и решил, что всё поместится и будет храниться в рабочем кабинете.
Когда я говорю о кризисном состоянии, то имею ввиду ситуацию с которой сталкиваются многие активно растущие предприятия, а именно — маркетинг отработал, контракты получены, а ресурсов не хватает или они не соответствуют постоянно растущими требованиям. Такой момент, по моему личному мнению, является переломным в эволюции предприятий и требуют максимальной отдачи от руководства и персонала.
Мне выпала роль антикризисного управленца среднего звена. Отдел, который мне достался, должен был обеспечивать фундамент для внедрения учётных систем. В тот момент нужно было спасать ситуацию. О передаче дел, в полном смысле этого слова, от уходящего руководителя мне, речь не шла. Передо мной была поставлена задача: «Удержать все проекты и всех абонентов».

Ко мне приставили исполнительного директора, в прямом смысле этого слова, он прилагал все усилия, чтобы ввести меня в «тему» по всем направлениям, ну и конечно же он контролировал динамику и тенденции, которые пришли со мной.
Я не стану рассказывать вам о том, какие физически затраты были сделаны для выравнивание ситуации, скажу лишь, что они были значительными.

Ну а теперь по шагам:

«Первая волна»

1. Первым делом мы, вместе с исполнительным, проанализировали тех. часть текущих проектов и сделали значительные поправки и улучшения, доработки в этом направлении шли на протяжении месяца или двух, параллельно с остальным.

2. Выстраивались отношения с толпой недовольных предприятий-абонентов. Другими словами, я сел на «первую линию» и начал обслуживать все входящие заявки. Тогда первая линия, в моём лице, работала с 6 до 22ч 5-7 дней в неделю. На гашение «первой волны» затрачено 2,5 мес.
«Работа с персоналом»

3. После «гашения на себе» «первой волны» началась активная работа с персоналом, а именно мы стали жестко делегировать. Жесткость заключалась в нулевой квалификации трудовых ресурсов. В тот момент не имело значение какой ценой решать вопросы, у меня конечно же были полные полномочия, но не было времени ни на поиск новых сотрудников, ни на обучение имеющихся, поэтому были предприняты шаги: написание инструкций и выработаны контрольные точки. Таким образом персонал был поставлен в условия, когда им сложно было ошибиться при работе, но конечно же, они ошибались, но работа пошла. За неисполнение инструкций были введены штрафные санкции.

4. Инструкции не решали всех проблем, они облегчали жизнь, но персонал оставался неквалифицированным, поэтому были введены в работу внутренние семинары. Темами для семинаров были те технологии, с которыми сталкивался отдела наиболее часто. Темы были разделены между сотрудниками, они готовили доклады и рассказывали остальным 2р. в неделю. Проведение таких мероприятий не только положительно отразилось на квалификации слушателей и докладчиков, но и дало чёткое представление о личностных качествах каждого сотрудника. За качественные доклады назначались премии.

5. Были найдены способы и меры для освобождения рабочего кабинета от производственного «хлама». Теперь в комнате были полноценные рабочие места, для всех кто там работал, и блестящий чистый пол.

6. Через 3,5 мес. от конца «первой волны» наступила полная стабилизация. Она продолжалась около трёх месяцев.

7. Через 3 мес. от конца полной стабилизации начались кадровые изменения. Был выделен первый сотрудник и уволен. Причиной для увольнения стала профессиональная халатность.

8. Был сформирован график отпускной компании, все сотрудники отдела, впервые, за последние несколько лет, побывали в отпусках, все летом, когда им хотелось (сотрудники этого не знали, но никто из бывших, ушедших сотрудников отдела ИТ не был в отпусках).

9. З\П младших сотрудников выросла за эти 9 мес. на 70%.

Поставленные руководством задачи были выполнены, а цели достигнуты. Проекты не были потеряны, не один абонент не ушёл из-за качества нашей работы.
В результате необходимой жесткой рабочей политики и слишком быстрого фин. роста сотрудников, возникла «поточность» кадров, к концу первого года моей работы штат полностью сменился, но эта ситуация уже не носила характер максимальной критичности и уже не угрожала существованию компании. Поскольку «поточность» — негативный фактор и теперь он стал иметь значение, предприняты действия для его остановки. Хочу так же отметить, что год в жёстких рамках положительно отразился на профессиональных и личностных качествах персонала, трое из четырёх ушедших сотрудников устроились в крупные корпорации, один вернулся к нам в роли сотрудник при клиенте в соседнем городе, где он проживает.

Подходит второй год моей деятельности, отдел состоит из 6 человек, включая меня. Компания переехала в новый просторный офис. У нас 2 человека на первой линии, 2 на второй и 2 профессионала. Продолжаем развитие по намеченным направлениям.

вывод ИТ из кризиса, кризис, ИТ

Виртуализация, контейнеры, ... - что дальше?

anonymous@undisclosed.example.com (Anonymous) — Thu, 29 Mar 2018 19:56:00 +0000

Виртуализация, контейнеры, ... - что дальше?

Для начала необходим небольшой экскурс в историю. Включаем машину времени (а кому-то вполне достаточно просто напрячь память) и поехали.

Давным-давно… Нет, неправда - все это происходило не более 60 лет назад. Поэтому так: совсем недавно…

Итак, первые компьютеры подразумевали однозадачный режим работы - в силу своего устройства. Далее был придуман многозадачный режим, когда несколько человек работали на одном компьютере (эпоха мэинфреймов). Кстати, первые гипервизоры появились в 60-70-х годах и использовались в основном для систем с разделением времени, повсеместного применения они не имели. Затем появились первые персоналки и они были именно персональными - за ними как правило работал 1 человек. Понимая, что один компьютер может одновременно выполнять несколько программ (для этого просто необходимо их быстро переключать), были созданы первые резидентные программы (они же TSR-программы). Я помню каким чудом мне показалось когда компьютер ОДНОВРЕМЕННО выполняет более 1 программы. Но запускать текстовый редактор и калькулятор одновременно оказалось не интересно и мысль инженеров пошла дальше - они решили исправить концепцию «1 физический компьютер - 1 операционная система» и появились системы виртуализации. Тут подтянулись производители железа - обычные процессоры стали аппаратно поддерживать виртуализацию. Отныне на одном компьютере можно запускать все что заблагорассудится, практически не стесняясь - пара копий Windows с кучей приложений, Linux и еще что-нибудь интересное. Правда, у этого решения есть один недостаток - ограничения самого компьютера, а именно объем памяти (как оперативной, так и постоянной). Умные люди и здесь нашли решение: зачем запускать полноценные виртуальные машины с установленной ОС внутри, драйверами и т.д. когда для работы программы вполне достаточно контейнера, который просто выполняет свою задачу? Так появилась контейнеризация, всем знакомая под названиями Docker. Это позволило увеличить плотность размещения процессов на серверах. «Один контейнер - один процесс» - вот такая философия. Если процесс упал или не нужен - не страшно, запустим снова и уничтожим.

Что же далее, что еще изобретут инженеры и разные умные люди?

А вот тут я уже вступаю на территорию домыслов и предположений, но, надеюсь, это будет по меньшей мере интересно.

Сейчас контейнеры используются для разнообразных задач: запуск приложений и сервисов, тестирование, всякие-разные CI/CD (continuous integration and continuous delivery) и т.д. Все это работает под управлением систем оркестрации - надстроек, позволяющих довольно легко и просто (а главное - автоматически) управлять этими контейнерами. Например, нагрузка на веб-сервис компании увеличилась - система оркестрации самостоятельно включила несколько физических серверов, создала нужные сервисы, раздала настройки для работы, запустила и после того как необходимость в них пропала - отключила все ненужное, включая оборудование чтобы оно не потребляло электроэнергию. Это то что мы имеем на текущий момент.

А что если все это же применить ко всей компьютерной технике. Представьте - вы включили свой компьютер/ноутбук/смартфон/кофейный аппарат - любое оборудование. Запустилась небольшая встроенная операционная система (ОС-загрузчик)и … и все. ОС-загрузчик самостоятельно далее проверил и загрузил из сети необходимые образы того программного обеспечения которым вы пользуетесь и запустил их по мере необходимости. Т.е. принцип «любое приложение - это процесс» стал главным и основным. Что это дает? Ну что же, вот первое и самое несложное что приходит в голову:

- «Процессу все равно где он работает» - какая разница где и на каком оборудовании запускать процесс? Он может работать на вашем ноутбуке, где-нибудь в облаке или на смартфоне. Например, вы хотите запустить калькулятор. Но он уже запущен у вашего коллеги - тогда достаточно просто передать ему данные для рассчета и получить ответ. Таким образом, человек даже и не поймет что ему всего лишь показался интерфейс, а не сам процесс.

- «Процесс запущен только тогда когда это необходимо». Это даст возможность существенно уменьшить объем памяти в устройствах. Если процесс не нужен - он автоматически через некоторое время убивается. Или замораживается, если не требуется непрерывная работа. Или перемещается на другое устройство или в облако.

- «Процесс отделен от данных» - это позволит быстро перезапускать процесс в случае его отключения по той или иной причине.Таким образом, например, можно сделать очень быстрое обновление процесса. Сначала в фоновом режиме загружается новая версия процесса, затем новая версия запускается и ей передаются данные от старого процесса, который при удачном переключении автоматически завершается. Обновление на лету позволит исключительно быстро устранять ошибки, которые в данный момент могут эксплуатироваться годами!

- «Данные хранятся и передаются в зашифрованном и сжатом виде» - таким образом перехватывать что-либо в канале не имеет смысла. А объем пересылаемых по сети данных не так уж и велик.

- «Всегда хранится несколько копий данных» - это позволит сделать практически 100% надежное хранилище с быстрым доступом. Количество и размещение реплик - автоматическое для увеличения как надежности, так и скорости доступа к данным.

Некоторые процессы можно использовать исключительно как средство отображения результатов. Пример - аналог текущего веб-браузера: одна закладка может обрабатываться прямо на вашем устройстве, а остальные - где-нибудь в облаке и на экран доставляться только результаты для отображения.

Сценарий работы системы на предприятии: утром пользователи включили/разбудили компьютеры (или используют принесенные с собой) - на них автоматически загрузились и запустились необходимые для работы процессы. Если какой-то процесс требует дополнительных ресурсов - он автоматически и абсолютно прозрачно для пользователя переместился в корпоративное облако (специально выделенное оборудование) или на соседние устройства - пока ваш коллега где-нибудь на совещании его компьютер не зря тратит электроэнергию. Не хватает собственных ресурсов? Оркестратор автоматически запросил в облаке необходимое количество ресурсов «на прокат» и после того как необходимость в них исчезла - вернул все ресурсы. Абонентская плата за отработанные ресурсы автоматически списалась.

Сценарий домашнего пользователя: с собой всегда телефон или ноутбук. Пришел на работу - процессы перескочили на вычислительные мощности работодателя, пошел с работы - опять переползли на устройство и/или в облако.

Сценарий хостинг-провайдера: купить кучу железа (часть для хранения данных, часть с большим объемом памяти), запустить систему оркестрации и дать доступ. Все остальное работает автоматически.

Таким образом, функционирование такой системы очень похоже на пузырьки в стакане: они существуют некоторое время и бесследно исчезают. Если вам не нравятся «пузырьки» - можно найти аналоги вроде понятия «кальпа», нынче это модно.

И вот нашел похожие размышления: http://blog.vadmin.ru/2016/06/10.html

А вот очень интересная система: https://www.qubes-os.org

что дальше, виртуализация, контейнеры, будущее прекрасно, мысли вслух