Tag Archives: SA

Multitasking in System Administration

Just a quick thought on multitasking in SA (or DevOps, if you prefer). There is a common knowledge that multitasking is bad, it hurts your performance, quality, and whatnot.

Here is a nice chart to illustrate the idea:

context-swtiching

Obviously, the above is more of a rule of thumb and here is a nice summarisation. However, there was another study on the matter by Harward’s professors S.Wheelwright and K.Clark that draw slightly different picture:

6a00d8341c500653ef014e606c9737970c

What’s important here is that the percent of time on tasks or performance actually maximises at 2 concurrent tasks. This is actually much more in line with my personal observations. You can also argue that in the field of SA we often have tasks that require significant amount of “wait time” when you kick something off and then simply wait for it to complete, so the latter graph has even more sense.

Links: 4 Sep

Technology:

  • grep tricks: grep files recursively, show only filenames where matching string was/wasn’t found.
  • Did you know that:
    • $ less <directory> — shows directory listing
    • $ less <archive.zip> — shows archive content
  • Teacher’s rumblings “Kids can’t use computers“. Agree to a T.
  • Going back to iPhone [from Android]. Again having pretty much the same thoughts.
  • Reddit: Lessons Learned From Mistakes Made Scaling To 1 Billion Pageviews A Month
  • Start a Web Search in a GUI Browser from the Command Line on Mac OS X
  • Screen recording to an animated GIF on Mac OS X
  • How to know from a child process that its parent exited:
    • a pipe between parent and a child, child gets SIGPIPE when parent exits
    • if a child has not detached, PPID becomes 1 when parent exits
    • Linux-specific: a child can ask kernel to deliver a signal when parent dies by specifying option PR_SET_PDEATHSIG in prctl() syscall
  • Two talks from YAC which I liked:

rpmdb locking issues, notorious on RHEL4/5, manifest as hanging rpm command. To see active locks:

# cd /var/lib/rpm; /usr/lib/rpm/rpmdb_stat -CA

Normally there should be no locks, given no rpm command is running. In case there are stale locks, just remove __db.00* files.

Other:

Sunlight in Europe and the USA in hours per year.

Links: 16 Aug

Technology:

  • Cloud server showdown: Amazon AWS EC2 vs Linode vs DigitalOcean. AWS performance sucks, Linode winner.
  • Pull mode in orchestration’s rising star, Ansible. Check also out the web interface — AnsibleWorks AWX
  • Learning from other disciplines, nice quote:

    I’ve seen several college of engineering departments that have a sign that says the equivalent of, “If you cheat in engineering classes, you will kill people later”. We don’t have that mindset yet with IT, but I think we should because eventually, we’ll be responsible for infrastructure that will kill people if we get it wrong.

  • knockd — a port-knock server. It listens to all traffic on an ethernet (or PPP) interface, looking for special “knock” sequences of port-hits. A client makes these port-hits by sending a TCP (or UDP) packet to a port on the server. When the server detects a specific sequence of port-hits, it runs a command defined in its configuration file. This can be used to open up holes in a firewall for quick access.
  • Here’s the example of why LISA conferences rock: 2007 paper On Designing and Deploying Internet-Scale Services. Must read for sysadmins.
  • How to automatically setup and keep ssh tunnel up with autossh, available from macports

Social:

  • Steven Fry, one of my all-time favourite actors and activists, wrote an open letter petitioning for moving Winter Olimpics 2014 from Russia to elsewhere, because of wilful LGBT community oppressions. On a related note, sexual orientation forms during prenatal period, influenced by hormone levels, and is therefore inborn feature. Read about it in Russian.

 

 

 

Первые 5 минут устранения неполадок на сервере

Винсент Виалле

First 5 Minutes Troubleshooting A Server by Vincent Viallet, 6 March 2013
Original post: http://devo.ps/blog/2013/03/06/troubleshooting-5minutes-on-a-yet-unknown-box.html

Translated by Ivan Pesin, July 2013

Когда наша команда еще занималась вопросами эксплуатации, оптимизации и масштабирования в предыдущей компании, нам приходилось иметь дело с отладкой медленно работающих приложений и целых инфраструктур, часто большого размера (представьте CNN или the World Bank). Горящие сроки, экзотические стеки технологий и недостаток информации обычно гарантировали незабываемые впечатления.

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

Войдите немного в контекст

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

Несколько обязательных вопросов, требующих ответа:

  • Какие конкретно наблюдаются симптомы? Подвисания? Ошибки?
  • Когда проблема была замечена впервые?
  • Воспроизводится ли она?
  • Есть ли закономерность (например, происходит каждый час)?
  • Какие были последние изменения в системе (код, сервисы, стек приложений)?
  • Влияет ли проблема на определенную группу пользователей (авторизированных, не авторизированных, с общим географическим расположением…)?
  • Имеется ли документация на архитектуру (физическую и логическую)?
  • Используется ли система мониторинга? Munin, Zabbix, Nagios, New Relic… Подойдет любая.
  • Ведется ли (централизированное) журналирование? Loggly, Airbrake, Graylog…

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

Кто здесь?

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

Что делали в системе?

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

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

 Что запущено?

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

«Слушающие» сервисы

Я предпочитаю выполнять эти команды отдельно, в основном потому что я не люблю смотреть на все сервисы одновременно. Тем не менее, netstat -nalp тоже подойдет и я бы не опускал опцию -n  (IP-адреса, мне кажется, воспринимаются лучше).

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

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

Процессор и память

Эти команды должны ответить на несколько вопросов:

  • Есть ли свободная память? Происходит ли своппинг на диск?
  • Насколько загружены процессоры? Сколько ядер доступно на сервере? Перегружены ли какие-то из них?
  • Что больше всего нагружает систему? Какое у системы значение средней нагрузки (load average)?

Аппаратная часть

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

  • Определить RAID-контроллер (есть ли у него батарея резервного питания?), процессор и количество доступных слотов памяти. Это может подсказать вам потенциальные причины проблемы и пути увеличения производительности.
  • Выяснить правильно ли настроена сетевая карта? Не работает ли она в режиме полудуплекса? На скорости 10MBps? Есть ли ошибки приема-передачи?

Производительность ввода-вывода

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

  • Проверяем свободное место: есть ли в системе полностью занятые файловые системы или диски?
  • Используется ли своп (si/so)?
  • Что занимает процессор: системные вызовы? пользовательские процессы? много ли времени крадется гипервизором (VM)?
  • Моя любимая команда — dstat. Какие процессы интенсивно используют ввод-вывод? Может быть MySQL грузит дисковую подсистему? Или это какой-то PHP-скрипт?

Точки монтирования и файловые системы

  • Сколько файловых систем смонтировано?
  • Есть ли файловые системы, выделенные для конкретных сервисов? (MySQL например?)
  • Какие указаны опции монтирования: noatime? default? Есть ли какие-то файловые системы смонтированные в режиме только для чтения?
  • Есть ли свободное место на дисках?
  • Нет ли больших удаленных файлов, которые продолжают удерживаться каким-либо процессом?
  • Есть ли место для расширения раздела, если проблема в свободном пространстве?

Ядро, прерывания и сеть

  • Распределены ли прерывания равномерно по всем процессорам? Возможно одно из ядер перегружено из-за прерываний от сетевой карты, RAID-контроллера, …?
  • Какое задано значение swappinness в системе? 60 подходит для персональных компьютеров, но не для серверов. Желательно, чтобы сервер никогда не использовал своп, иначе во время чтения/записи данных на диск, процессы вытесненные в своп окажутся заблокированными.
  • Достаточно ли велико значение conntrack_max для существующего трафика?
  • Как долго TCP-соединения могут находится в различных состояниях (TIME_WAIT, …)?
  • netstat может быть немного медленным при выводе всех существующих соединений, тогда используйте ss -s, чтобы быстро получить краткую статистику.

Посмотрите статью про настройку TCP в Linux, в ней есть полезная информация на эту тему.

Системные журналы и сообщения ядра

  • Ищите любые сообщение об ошибках или предупреждения. Есть ли сообщения о слишком большом количестве соединений в conntrack?
  • Есть ли сообщения об аппаратных ошибках или ошибках файловой системы?
  • Коррелируется ли время между ошибками в журналах и предоставленной информацией о проблеме?

Задания cron

  • Есть ли задания, которые выполняются слишком часто?
  • Есть ли персональные конфигурационные файлы cron, спрятанные от постороннего взгляда?
  • Выполнялось ли какое-либо резервное копирование в то время, когда возникла проблема?

Журнальные файл приложений

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

  • Apache & Nginx; посмотрите журналы доступа и ошибок, ищите ошибки 5xx, возможные ошибки limit_zone.
  • MySQL; посмотрите есть ли ошибки в mysql.log, следы поврежденных таблиц, работающий процесс восстановления innodb. Посмотрите журнал медленных операций и определите есть ли проблемы с диском, индексами или запросами.
  • PHP-FPM; если включен журнал php-slow, покопайтесь в нем и попробуйте найти ошибки (php, mysql, memcache, …). Если журнал выключен, активируйте его.
  • Varnish; проверьте отношение hit/miss в varnishlog и varnishstat. Не пропущено ли правило в конфигурации, в результате чего запросы конечных пользователей проходят до бекэнда, минуя varnish?
  • HA-Proxy; какой статус у бекэндов? Правильно ли работает проверка здоровья бекэндов? Не переполнена ли очередь запросов на фронтэнде или бекэндах?

Заключение

После этих первых пяти минут (плюс-минус десять), у вас должно будет сформироваться более полное понимание ситуации:

  • Что запущено.
  • Связана ли проблема с вводом-выводом/аппаратной частью/сетевой подсистемой или конфигурацией (плохой код, настройки ядра, …).
  • Есть ли знакомые шаблоны: плохое использование индексов БД, слишком много процессов apache, и т.п.

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

 

vim syntax highlighting for cfengine3

Major part of my work these days is connected with cfengine3 and writing promises. I’m kind of a vim-guy, so clearly I’m using it when writing cfengine promises and when you write a lot of code, you’d definitely want to make your development environment comfy and snug. Part of being comfy and sung in my understanding is syntax highlighting, which tremendously simplifies reading code and makes you spot typos and other sorts of mistakes right away.

There’s an initial version of syntax highlighting for cfeninge, written by Neil Watson available on github. However, I wanted more sophisticated highlighting functionality, so I took Neil’s work and spent couple of weekends extending it. Here are some screenshots with results of that extension (click to see them full-size):


At the moment, the module highlights correctly cfengine-stdlib.cf and all cf files in examples/ directory of cfengine with exception of knowledge-related promises. There’s still a lot of work to do – a bit of refactoring and then, perhaps, a rudimental syntax checker – but it seems to me already usable, so I decided to release it’s “first” version.

The syntax highlighting module is available at https://github.com/ivanpesin/vim_cf3/tree/master/syntax. To activate it, you’ll need to save cf3.vim in ~/.vim/ directory and add following lines to your ~/.vimrc:

 

Bundle execution time randomization in cfengine3

Read this article in Russian.

In our environment we use cfengine to manage servers across the organization. Having a fairly large infrastructure we have to give a lot of thought to such things as smoothing the load on cfengine hubs and other parts of the infrastructure.

This article presents some approaches to bundle execution time randomization. This might be useful when you have a bundle which is going to affect a lot of servers and you don’t want it to execute simultaneously across a whole lot, thus causing a pressure point and possible event storms.

The first approach which comes to mind is splayclass() function, which defines a class if the system clock lies within a scheduled time-interval that maps to a hash of the first argument – arbitrary string, usually set to fqdn. Different strings will hash to different time intervals, and thus one can map different tasks to time-intervals. The code utilizing this function looks like this:

This will execute report at a random moment every hour.

A nuisance with this function is that it’s somewhat limited, having only “hourly” and “daily” policies. With “hourly” policy, the class will be defined for a 5-minute interval every hour, and with “daily” policy then the class will be defined for one 5-minute interval every day. This might be either too frequent or too seldom for a specific case. This also might be a problem if you use an cfengine run interval different from a default one.

To address this nuisance we might employ dist keyword in classes’ definition which generates a probabilistic class distribution. For example:

In this example class “percent_of_runs_15”  will be defined in 15 out of (15+85=) 100 cases or in 15% of cf-agent runs. Considering that cf-agent runs with 5 minutes interval by default, that makes 15% out of (24*12 =) 288 runs per day, or 43 runs, or approximately twice per hour at a random moment. Tuning the sum and the initial number we might change the random frequency at which the class will get defined.

Dist might give us even more flexibility, for example when we need the bundle to execute at the random hour every 12 hours, but at that hour we’d like bundle to run every 5 minutes. This might be needed when bundle requires multiple runs to fix things (deleting stuff from a file is a good example). So for that matter we might combine dist keyword with persistent classes, like in:

This approach seems to be more flexible, but it also contains an issue – due to its nature, dist is probabilistic and that means it doesn’t guarantee that the percent of distribution will be exact. In fact, you should keep in mind that +/- error is a norm here and, for instance, running the 15%/85% example drew results from 13% to 18% for 15% class.

We can also apply the approach with persistent classes to splayclass() function in the following manner:

Which would allow us to execute a report (or bundle) every 5 mins throughout a random hour of the day.

 

Создание DevOps-команды

Брайан Генри

Building a DevOps Team by Brian Henerey for agilesysadmin.net

Original article: http://agilesysadmin.net/building-a-devops-team
Translated by Ivan Pesin, February 2012

Предыстория

С тех пор, как я начал работать в Sony в августе 2008-го, моя должность менялась 3 раза. Около года назад, я принял руководство командой, в которую я пришел с самого начала. И хотя это была, с любой точки зрения, разваливающаяся команда, я был очень доволен возможностью её изменить. Я знал, что оставшиеся люди были очень недовольны, и могли уйти в любую минуту, потому у меня было несколько неотложных задач:

  • Брать новых людей!
  • Удерживать тех, кто есть.
  • Брать новых людей!

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

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

Начало

Ещё год назад я никогда не слышал слова DevOps. Если вы в таком же положении, то есть много статей о том, что представляет собой DevOps:

И чего он не представляет:

Тем не менее, я подозреваю, что у некоторых возникнут проблемы с тем, чтобы найти действительно стоящие перлы, среди водянистой болтовни. Вот хорошее место, чтобы начать: Приступая к работе с подходом DevOps. Этот гигантский список ссылок на тему DevOps, собранный Патриком Дебуа (Patrick Debois), ясно продемонстрирует, почему не стоит пытаться прочесть всё о DevOps: devops-закладки.

Если же вы уже в курсе дела, DevOps вам нравиться и вы хотите построить команду вокруг этого принципа, то вот как это делал я.

Налаживание связей

Понимание, что же такое DevOps у меня оформилось только после того, как я начал об этом говорить с другими людьми. К счастью, в Лондоне есть очень активное сообщество DevOps, и поэтому у меня было достаточно возможностей разговаривать на эту тему. Неутомимый Гарет Рашгров (Gareth Rushgrove) проводит множество мероприятий, а The Guardian их часто принимает у себя. Я принимал участие в сессиях, где обсуждалась Continuous Integration, Deployments, Google App Engine, Load Balancers, Chef, CloudFoundry, и т. д. Я обнаружил, что люди удивительно открыто говорят о своих технологиях, процессах, культуре, трудностях и успехах.

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

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

Результат: я познакомился, а после и взял на работу, со Стивеном Нельсоном-Смиттом (Stephen Nelson-Smith) из Atalanta-Systems. (Он – автор блога agilesysadmin.net и пишет в твиттере под ником @Lordcope).

Рабочее определение DevOps

Если вы собираетесь нанимать людей, ориентированных на DevOps, неплохо иметь для себя его рабочее определение. Мне нравятся «столпы DevOps»  (Culture, Automation, Measurement, Sharing = CAMS) предложенные Джоном Уиллисом (Что означает DevOps для меня):

  • Культура
  • Автоматизация
  • Измерение
  • Обмен знаниями

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

Требования к DevOps-кандидатам

Хотя я и видел вакансии на DevOps, я не считаю это должностью. В своей вакансии я только упоминал, что ищу «подкованных в DevOps», а потом изменил это на «DevOps-ориентированных» или что-то в этом роде. Объявление про вакансию истекло, и я собирался его выкинуть, но Р. И. Пинар (R.I.Pinearr) у себя в твиттере назвал его «идеальным описанием работы devops». Я очень люблю последовательно уточнять описание вакансии до тех пор, пока в требованиях не остается лишь то, что мне действительно требуется, и что можно чётко оценить в процессе собеседований. Но то, как составлять описание вакансии, выходит далеко за пределы этой статьи. Вкратце, я искал людей:

  • с хорошими навыками решения проблем
  • исполнительных и энергичных
  • хорошо вписывающихся в команду (очень трудно оценить)
  • с широким набором профессиональных навыков (LAMP, Java, C++, Ruby, Python, Oracle, Scaling/Capacity, High-Availability, и т.д., и т.п.)

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

Рекрутеры

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

Отбор резюме

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

Первое собеседование – удалённое техническое тестирование

Вот здесь начинается самое интересное! Я не знаю, лондонская ли это специфика, но у меня было очень много кандидатов из других стран, которые хотели присоединиться к команде. Для тех, у кого было хорошее резюме, а рекрутер ручался за хороший английский, я разработал отличный скрининг-тест, который можно было проводить удалённо. Это позволяло экономить на поездке в Лондон и проживании, а также быстро закончить разговор, если дела шли не лучшим образом. Вот как это выглядело:

  • Я выслал кандидату или рекрутеру ссылку на инстанс ec2, который я запускал минут за 20 до собеседования.
  • В инстансе был запущен веб-сервер, который содержал инструкцию для теста. Она лишь информировала, что кандидату будет нужен терминальный клиент, например Putty, если используется Windows.
  • В оговоренное время я звонил кандидату. Я объяснял, что тест состоит из двух заданий. Первое задание ориентировано на системное администрирование, и на него выделяется 20 минут. Второе задание – на программирование, и на него можно использовать всё оставшееся время. Звонок закончится через час.
  • Объясняю правила: вся работа должна быть выполнена на инстансе ec2, у кандидата есть тестовая учетная запись с паролем и root-доступ через sudo. Для выполнения задания можно пользоваться любыми ресурсами. Использование google, man-страниц, библиотек не только разрешено, но и предполагается.
  • Объясняю, что я от них хочу: они должны разговаривать со мной, рассказывая, как и о чём они думают, демонстрируя мне свой процесс решения задачи. Мне гораздо важнее этот диалог, чем смогут ли они решить какую-либо из поставленных задач.
  • Добавляю, что мы будем использовать Screen и я буду видеть всё, что они вводят.
  • Подменяю файл index.html с полными инструкциями, отмечаю время и говорю кандидату начинать.

Задачи

1) На самом деле очень простая: установить WordPress и настроить его для корректной работы. Уловка в том, что mysql мы предварительно поставили и сломали, а теперь наблюдали, как кандидаты ломали себе голову над тем, что ж такое происходит. Для опытного администратора это детские игрушки.

Как правило, мне приходилось собеседовать людей, больше ориентированных на разработку, чем администрирование. И практически сразу было понятно, насколько хорошо человек разбирается в Linux-системах. Было интересно видеть, какие предположения делали люди о самой системе (я ни разу не упоминал, что за операционная система установлена в инстансе; некоторые просто решили, что это Ubuntu). Некоторые люди читали инструкции, а некоторые – нет. В них был указан пароль для mysqladmin, но тем не менее были такие, кто искал как сбросить утерянный пароль. Один парень потратил 10 минут, пытаясь зайти по ssh на http://ec2… . Я сделал ему скидку из-за нервного напряжения, но он продолжал в том же духе и я вскоре закончил собеседование. Он жаловался на языковой барьер (он из Восточной Европы) и сказал, что если бы я только яснее выражался… Если я не могу с ним нормально общаться, то, я думаю, это весьма серьезная проблема, в независимости о того, чья это вина.

2) Мы давали немного почищенные журнальные файлы от Tomcat с реальным приложением, которое мы поддерживаем, и просили написать скрипт для разбора этого журнального файла на любом языке, который выберет кандидат. Нас интересовало, чтобы скрипт выводил вызовы методов, их число, частоту, среднее и 90-ю персентиль задержки. Предпочитаемым языком был Ruby, но кандидат был волен выбирать любой.

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

В зависимости от того, сколько времени было потрачено на первую задачу, эта часть собеседования часто была для меня очень скучной. Я оставался на связи на случай, если будут вопросы, просил объяснить свой подход перед тем, как начать кодирование, но после этого всё, что мне оставалось, это читать почту и т. п. Когда проходило 60 минут от начала собеседования, я пояснял кандидату, что он может продолжать работать над заданием столько, сколько ему на это понадобиться, после чего прислать мне письмо. После чего я заканчивал разговор, сказав перед этим, что мы свяжемся с ними, после того, как рассмотрим их присланный код.

Результаты

Я провёл через этот процесс несколько кандидатов. Когда мы только начали формировать тест, кроме меня в разговоре принимало участие ещё несколько человек из моей команды, но это оказалось слишком затратным в плане времени и, кроме того, пугало некоторых кандидатов. Ограничение по времени первой задачи стало огромным шагом вперёд, а как только к нашей команде присоединился Стивен Нельсон-Смит, у меня появился человек, который мог оценить код на ruby лучше меня. Мы все считаем, что описанный процесс тестирования чрезвычайно хорошо демонстрирует навыки кандидатов, и я крайне его рекомендую.

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

Этап 2 – личное собеседование

Второй этап состоял из нескольких частей:

  • Неформальный разговор за кофе/обедом/ужином, длинной до часа. Я объяснял, что я ищу, кандидаты рассказывали про себя, и мы оценивали, на сколько подходим друг другу.
  • Упражнение на решение гипотетической проблемы у доски: вам звонит заказчик и говорит, что получает пустую страницу, когда заходит на http://yoursite.com. Ваши действия? Можно немного поимпровизировать с темой самой проблемы, но у неё должно быть две цели: показать подход человека к решению проблем и с архитектурами какой сложности он имел опыт работы.
  • Два часа парного программирования с любым человеком из моей команды. Обычно, это самая настоящая работа, которую нужно сделать. Это может быть cookbook для chef, или тест в cucumber, и т.п. Нам нужно выяснить, насколько комфортна тесная работа с этим человеком. Моя команда часто практикует парное программирование. Готовы ли мы работать с ним в паре день за днём?

Этап 3 – мой босс + любой член команды, которые ещё не встречался с кандидатом

  • Этот этап обычно очень свободный, хотя мой босс имеет своих собственные методы для оценки людей.

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

Отличный результат

Один из лучших людей, которых я нанял, знал не только C, Java и Linux, но и написал пример приложения на Ruby, потому что знал, что нам нужен был человек, умеющий писать на ruby. Его программа находила кратчайший маршрут между станциями лондонского метро, правда только по количеству остановок, а не времени в пути. Мне такая инициативность сказала о многом, и она полностью подтверждается с тех пор, как он присоединился к нашей команде. Жаждет новых знаний и хочет их применять. Любая проблема или задача для него «это просто». Единственная моя проблема с ним, это то, что он считает проблему решенной, как только придумает, как её решить. Это, конечно, немного шутка. На днях я ему сказал, что он объявляет задачу решённой, если твёрдо уверен, что ему потребуется ещё семь своих действий для её решения.

После найма

Что теперь? Ну, приём правильного человека – большое событие. Мы отмечали приход каждого человека, в противоположность типичным «прощальным столам», когда люди уходят. То, как я управляю командой, я ещё напишу (я надеюсь), но хочу сделать небольшой комментарий. Нанимая людей, в соответствии со своим видением, я должен буду отвечать перед ними. Всякий раз, когда я понимаю, что причиной моего решения стала «политика», я знаю, что это нужно менять.

Об авторе

Брайан Генри возглавляет Operations Engineering из Online Technology Group в Sony Computer Entertainment Europe. Его увлечения включают Devops, Tool-chains, Web Operations, Continuous Delivery и Lean thinking. Сейчас он занимается разработкой линий автоматизированных инфраструктур, с применением Ruby, Chef и AWS, запуская само-обслуживаемые, создаваемые по требованию, информационные окружения для разработки и тестирования в Sony’s Worldwide Studios.

Избыточность

Мэт Симмонз

Day 13 – Redundancy by Matt Simmons

Original article: http://sysadvent.blogspot.com/2009/12/day-13-redundancy.html
Translated by Ivan Pesin, January 2012

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

Но постойте-ка, обычно так не бывает. Что, в общем-то, забавно, потому что двигатели у самолетов отказывает постоянно. Серьезно, это случается так часто, что Федеральное авиационное агентство даже не ведет статистику отказов. Вот тут пилоты прикидывают, что отказы авиадвигателей происходят с частотой от одного раза на каждую тысячу летных часов, до одного раза на каждые десять тысяч часов. Вроде как нечасто. Но так кажется до тех пор, пока вы не примете во внимание, что в любой день, в воздухе над США выполняется около 30 000 коммерческих рейсов. Тем не менее, каждый день, вы просыпаетесь, ходите на работу, читаете новости и не слышите страшных историй про падающие с небес самолеты, хотя есть все шансы, что где-то в этот день у самолета отказал двигатель. Мало того, если вы много летаете, то вполне возможно, что такое случалось и с самолетом на котором вы летели. Только вы про это не узнаете, никто не обязан вам о таком рассказывать.

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

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

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

Мы, в IT, можем многому поучится у авиационной отрасли. Это одна из немногих областей, где требования к безотказной работе выше, чем у нас. Кроме того, они в деле-то подольше нашего будут. За время своего существования, они кое-чему научились, в том числе тому, что у вас должен быть порядочный запас прочности (читай: избыточность), если вы хотите, чтобы ваш сервис имел действительно высокую доступность.

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

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

Сами дата-центры предоставляют питание от двух отдельных электросистем, каждая со своими аккумуляторными батареями и генераторами. Высококачественные дата-центры для обеспечения надежности используют схемы N+1 и N+2. Это означает, что на каждые N единиц оборудования, необходимого для нормальной работы, у них есть одна (или две) запасная. Самолеты с 2-мя двигателями используют схему N+1, с 4-мя двигателями — N+2.

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

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

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

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

Подключение серверов в локальной сети одним кабелем очень рискованно. Всегда есть риск зацепить и выдернуть провода. Сетевые карты сбоят, а порты на свичах умирают. Сервер станет недоступен в любом из таких случаев. Чтобы избежать возникновения подобных проблем, современные сервера выпускаются с двумя встроенными сетевыми картами. Раньше я не понимал зачем, но потом узнал об объединении интерфейсов (interface bonding).

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

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

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

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

Но даже кластер серверов не поможет в случае катастрофического происшествия.

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

К счастью, обезопасить себя от этого можно. К несчастью, это непросто и недешево.

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

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

Дополнительное чтение:

Сисадминская притча: официантка и стакан воды

Том Лимончелли

A SYSTEM ADMINISTRATION PARABLE: THE WAITRESS AND THE WATER GLASS
by Tom Limoncelli

Original article: http://www.usenix.org/publications/login/2010-10/openpdfs/limoncelli.pdf
Translated by Ivan Pesin, December 2011

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

Стояло лето 2008 года, точнее июль. Так случилось, что три вечера подряд я ужинал в трех разных ресторанах. В каждом из них по-разному решали вопрос с пополнением моего стакана воды и это привлекло мое внимание.

Режим «по прерыванию»
Пакетный режим с прерываниями
Режим делегирования
Организация работы
Задавайте вопросы
Аварийные ситуации
Варианты пакетных режимов
Делегирование и специализация
Автоматизация
О чем стоит подумать
Ссылки

Режим «по прерыванию»

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

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

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

Результат:

  • Лучший вариант: официантка была доступна немедленно и мы быстро получали воду.
  • Худший вариант: мы ждали 5–10 минут, пока она к нам подойдет, после чего получали воду быстро. Но пока она наполняла наши стаканы, мы были без воды, которая еще в них оставалась.
  • В общем: так себе.

Пакетный режим с прерываниями

В среду я ужинал в модном ресторанчике, который находится в Нью-Йоркском районе Адская кухня. Название района отражает дурную славу, которую он имел до конца 80-х годов прошлого века. Позднее он был облагорожен и сейчас там располагается множество отличных ресторанов. Культура работы официантов в Нью-Йорке имеет очень высокие стандарты. Эти люди усердно работают, мало получают и живут в местах, где стоимость жизни очень высока. Чаевые в этом городе начинаются с 20% совсем неспроста. С тех пор как я начал работать в Нью-Йоркском офисе Гугл, я нашел тут много отличных ресторанов.

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

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

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

Результат:

  • Лучший вариант: вода доливалась без просьбы.
  • Худший вариант: также, как и в Friendly’s, но стаканы всегда были у нас на столе и меньше нужно было мыть посуды.
  • В общем: иногда мы ждали, но обычно все было без задержек и напоминаний. В целом, очень хорошо.

Режим делегирования

Вечер четверга я провел за ужином в Skylight Diner, расположенном в Нью-Йоркском районе Клинтон. Skylight — это греческая закусочная. Есть несколько вещей, которые нужно знать о греческих закусочных, типичных для Нью-Йорка и Нью-Джерси. Во-первых, они называются «греческими» не потому, что там подается греческая кухня, а потому, что их владельцы обычно греческого происхождения. Нью-Йорк — это город иммигрантов и это одна из тех особенностей, которые делают его таким замечательным. Во-вторых, меню в этих заведениях огромные: страница за страницей следуют блюда от гамбургеров и пасты до морепродуктов и соте. В некоторых даже есть греческие блюда. В-третьих, блюда обычно отличные, а порции — поразительно большие. Наконец, если вы слышите «закусочная» и представляете страшненький фастфуд, вы ошибаетесь на 100%. Чтобы искупить свою ошибку, сходите в такую закусочную, когда голодны. Очень голодны.

Официантки в Skylight никогда не пополняли наши стаканы с водой, это была обязанность их помощников — басбоев. Они постоянно обходили столы, забирая пустые тарелки и наполняя наши стаканы водой. Если стакан с водой у кого-то все-таки пустел и он обращался к официантке, то она подзывала ближайшего басбоя и говорила: «Más agua aquí».

Это сила делегирования или, можно сказать, автоматизации.

Результат:

  • Лучший вариант: вода доливалась без просьбы.
  • Худший вариант: вода доливалась, сразу после просьбы.
  • В общем: практически всегда был лучший вариант.

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

Результат:

  • Лучший вариант: вода доливалась по необходимости.
  • Худший вариант: ждать, пока нальют новый графин с водой.
  • В общем: обычно как в лучшем варианте.

Организация работы

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

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

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

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

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

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

Можно записать запрос в свой список задач или открыть тикет в системе запросов.

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

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

Задавайте вопросы

Раньше я считал, что все запросы срочные. Теперь я всегда спрашиваю «когда вам это нужно будет?». Удивительно, как много запросов, которые звучат неотложными, оказываются не такими и срочными, если только об этом спросить. «Да я на днях лечу в Бостон, сможешь это сделать до моего возвращения?» или «Он выходит на работу 18-го октября, нужно сделать до этого момента».

Поразительно, как часто мы забываем задать этот вопрос.

Возможность записывать задачи зависит от наличия места, где их можно записать. Один из способов — это список задач в ежедневнике (мои рекомендации приведены в [1]). Однако, в дополнение, очень важно иметь систему отслеживания запросов, которая позволяет пользователям ставить задачи не отрывая вас от текущих задач. Существует множество типов таких систем автоматизации службы поддержки или отслеживания запросов. Они бывают как с открытым исходным кодом, такие как Request Tracker [2] и OTRS [3], так и платные.

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

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

Аварийные ситуации

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

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

Варианты пакетных режимов

Свою работу в пакетном режиме можно организовывать по-разному.

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

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

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

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

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

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

Делегирование и специализация

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

Специализация становится возможной только с ростом компании. Как правило, отдел ИТ в маленькой фирме начинается с одного человека, отвечающего за всё.

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

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

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

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

Автоматизация

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

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

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

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

Какие из них используете вы?

О чем стоит подумать

  1. В каком режиме вы работали последнюю неделю: по прерыванию, пакетном, делегирования, автоматизации или писали системы самообслуживания?
  2. Какие три задачи на работе вы можете выполнять в пакетном режиме?
  3. Когда кто-то делает запрос, как вы определяете насколько он срочен?
  4. Какие есть специализации в вашей команде? Являются ли они официально признанными?
  5. Как бы вы реорганизовали то, как делаете свою работу? Какое влияние это окажет на вас? На ваших пользователей?
  6. Как бы вы реорганизовали работу своей команды или ИТ-отдела? Что в результате станет лучше, а что хуже для вас и ваших пользователей?
  7. Отвечая на вопросы 5 и 6 вы предложили много изменений. Какие из них будут иметь наибольшее влияние? А какие сулят наиболее быстрый результат?

Ссылки

[1] Thomas A. Limoncelli, Time Management for System Administrators (O’Reilly Media, 2005).
[2] RT: Request Tracker: http://www.bestpractical.com
[3] OTRS: http://www.otrs.org