Tag Archives: devops

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: Nov 8

You know, I’m totally baffled by the contrast in quality of Obama for America 2012 and ObamaCare projects. The first one was top-notch bleeding-edge technology project carried out with gleaming excellence, the second though has been a model failure by all means.

4Gb/s, 10k requests per second, 2,000 nodes, 3 datacenters, 180TB and 8.5 billion requests. Design, deploy, dismantle in 583 days to elect the President. #madops

Tweet above summarises the challenge for OFA2012 project and here are few links about it:

Calamities with HealthCare.gov look like they’ve been using services of the /dev/null-as-a-service kind. Facepalm.

Got an email from google+ telling me I’m eligible for custom URL. Made me even log in, found out it was still as revolting as it had been for a year or so, and on top of it, my very first posts to google+ were missing. Actually, one of the reasons I started to use G+ was to save interesting links I had come across, and as you might imagine, I’m thrilled to discover they wipe my older posts. So expect some flashbacks, as I’m not going to loose interesting stuff and will repost it here.

Continuing to catch-up on links:

Technology

  • The Ars Technica Review of Mac OS X Mavericks, in-depth, long, and interesting reading.
  • Recommended server-side SSL configurations
  • DevOps Look-fors — the way of assessing your processes maturity
  • Beej’s Guide to Network Programming
  • Question asked on many interviews — can root kill init process? It depends.
  • Algorithms part 2 commenced!
  • Boostrap 3 add-ons collection (in Russian).

English

Other

  • Banksy turns 50$ painting into 1M$ treasure
  • How a plan becomes policy:

In the beginning was the plan.
And then came the assumptions.
And the assumptions were without form.
And the plan was without substance.
And darkness was upon the face of the workers.
And they spoke among themselves saying,
“It is a crock of shit and it stinketh.”
And the workers went unto their supervisors and said,
“It is a pale of dung and none may abide the odor thereof.”
And the supervisor went unto their managers and said,
“It is a container of excrement and it is very strong, such that none may abide by it.”
And the managers went unto their directors, saying,
“It is a vessel of fertilizer, and none may abide its strength.”
And the directors spoke among themselves, saying to one another,
“It contains that which aids plant growth and it is very strong.”
And the directors went unto the vice presidents, saying unto them,
“It promotes growth and is very powerful.”
And the vice presidents went unto the president, saying unto him,
“The new plan will promote the growth and vigor of the company, with powerful effects.”
And the president looked upon the plan and saw that it was good.
And the plan became policy.
This is how shit happens.

http://ogun.stanford.edu/~bnayfeh/plan.html

  • Jennifer’s the winner: Six Decades of the Most Popular Names for Girls, State-by-State

Popular Girl’s Names

 

Links: 21 July

Technology

Education

My most favourite coursera course Algorithms by Kevin Wayne and Robert Sedgewick of Princeton is coming back with new session this autumn; my passionate recommendation to take it if you’re doing any kind of programming, either to improve your skills or just get a lot of fun:

Bootstrap-related

IT in Ukraine (in Russian)

Miscellaneous

Petit Fille, liked choreography a lot:

Первые 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, и т.п.

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

 

Создание девопс-команды, часть 2

Брайан Генри

Building a DevOps Team, part 2 by Brian Henerey for agilesysadmin.net

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

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

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

Критерии успеха

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

  1. Могут ли они выполнять нужную работу?
  2. Станет ли команда с их приходом лучше?
  3. Есть ли чему нам у них поучится?
  4. Могут ли они быстро осваивать новые технологии и языки?
  5. Какая помощь им будет нужна от меня и команды?

Самооценка

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

Руководство по самооценке:

0
 Опыта нет.
1
 Могу прочесть программу, внести маленькие изменения в существующие программы или изменить настройку уже установленных систем с книгой под рукой.
2
 Могу написать «Здравствуй, мир!» без книги, при необходимости попытаться разобраться в том, как работает система.
3
 Могу использовать основные средства без особой помощи, полностью управлять небольшим окружением.
4
 Могу разрабатывать программы или разворачивать системы среднего размера, используя всю основную функциональность (без книги) и некоторую специфическую (с книгой). Достаточное представление об архитектуре для  решения нетривиальных проблем.
5
 Могу разрабатывать программы или разворачивать системы большого масштаба, используя всю основную (без книги) и значительную часть специфической (часть с книгой, часть без) функциональности.
6
 Могу разрабатывать программы большого масштаба или разворачивать новые системы с нуля.
7
 Представление и умение применить менее известные возможности.
8
 Глубокое понимание тонких моментов и малоизвестных возможностей.
9
 Мог бы написать книгу, но пока не написал.
10
 Написал про это книгу (должна быть такая книга).


____
 Сети TCP/IP
____
 Архитектура Unix/Linux
____
 Системное администрирование Unix/Linux
____
 Алгоритмы и структуры данных
____
 C
____
 C++
____
 Java
____
 Python
____
 Perl
____
 Ruby
____
 Shell Scripting
____
 SQL и/или администрирование БД
____
 Скриптовой язык на ваше усмотрение, не перечисленный выше: __________________
____
 Сборочные системы и/или непрерывная интеграция
____
 Тестирование производительности и/или планирование мощностей
____
 Управление проектами и/или ITIL
____
 Конфигурационное управление (Puppet, Chef, Cfengine, и т.д.)
____
 Поддержка производственных сред или сред высокой доступности
____
 Amazon Web Services (или другие «облачные» технологии/сервисы)

Сравнение результатов самооценки

Эта диаграмма оказалась действительно полезной в том смысле, что заставила меня задуматься о том, что же я хочу. Кандидат-8 набрал значительно больше очков, чем Кандидат-1, но значит ли это, что я больше хочу именно его? Например, до того, как я ввел весовые коэффициенты, кто-то, хорошо разбирающийся в Ruby, Python, Perl и Bash, мог набрать очень много очков. Но мне гораздо нужнее был человек, который мог легко учиться, чем разбирающийся во всех этих языках. В конце концов, я объединил эти категории в одну, давая одно-два дополнительных очка за широту знания, чем уменьшил эффект этих технологий на конечный результат.

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

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

Удаленный технический тест

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

  1. iptables фильтровал входящий трафик на 80-м порту внешней сетевой карты.
  2. 80-й порт был уже занят процессом, который нужно было убить.
  3. Этот процесс порождался из бесконечного цикла, так что каждый раз, когда его убивали, он запускался заново.
  4. Конфигурационные файлы Apache уже были в системе, и задавали для него 81-й порт.
  5. Мы не давали root-пароля к MySQL.

В итоге, мы хотели убедиться, что кандидаты имеют базовые навыки в системном администрировании и достаточные знания о Linux. Использование таких вещей, как netstat, telnet, pstree и kill, составляет базовый набор навыков, а поскольку я давал людям всего один час на прохождение теста, времени на поиск в гугле было очень мало.

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

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

Персональные собеседования

  1. Кандидат проводил 30-60 минут, программируя в паре с одним из членов моей команды. Писались простые вещи, обычно на языке, которого кандидат не знал. Если он не знал руби, они писали коаны руби. Основной целью было понять, сможем ли мы проводить много времени в тесной работе с кандидатом.
  2. Мы также проводили несколько вполне стандартных интервью, обсуждая резюме кандидата и рассказывая ему о той роли, которую ему предстояло выполнять в команде. Здесь же проходили теоретические собеседования у доски о программировании и алгоритмах.

Задание по программированию

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

Конец – это начало

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

Создание 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.

Девопс с точки зрения системного администратора

Автор: Патрик Дебуа (Patrick Debois)
Перевод: Иван Песин (Ivan Pesin)

Введение

Не смотря на то, что общепринятого определения девопс нет (как и определения облака), его идеи построены вокруг четырех принципов: культура, автоматизация, измерение и обмен знаниями (Culture, Automation, Measurement and Sharing, CAMS). В этой статье мы рассмотрим, как это влияет на традиционные подходы системных администраторов.

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

Проблема

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

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

Культура сотрудничества

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

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

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

Не смотря на то, что системные администраторы всегда сотрудничали с разными отделами, это никогда не считалось стратегическим преимуществом. Культура девопс направлена на продвижение постоянного сотрудничества между вертикалями (Здесь и далее, я использовал слово «вертикаль» для перевода английского «silo», поскольку обмен информацией между вертикалями в организациях часто отсутствует. Information silo — это система, неспособная к сотрудничеству с другими, релевантными системами. — Прим. пер.), с целью лучшего удовлетворения потребностей бизнеса. Это ведет к «friction-less» IT («безупречному ИТ») и стимулирует междисциплинарный подход и совместную работу отделов.

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

Культура обмена знаниями

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

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

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

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

Пересмотр автоматизации

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

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

Пересмотр измерений

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

Секретный соус

Несколько «молодых» компаний являются лидерами в применении этих подходов. Amazon, с их правилом двух пицц (если команда, работающая над одним проектом, может съесть больше двух пицц, то она слишком большая — Прим. пер.), Flickr, с политикой десяти обновлений в день, были одними из первых лидеров, но теперь всё более традиционные компании, как, например, National Instruments, видят ценность такой культуры сотрудничества. Теперь они называют культуру сотрудничества «секретным соусом», который позволит им оторваться от конкурентов. Почему? Потому что, такой подход позволяет перестать считать людей ресурсом, а начать считать, что это у людей есть ресурс для решения проблем, которые существуют в этом сложном мире, называемом ИТ.