Презентація з лекції “По дорозі з хмарками”

Всім привіт!

Викладаю презентацію до лекції “По дорозі з хмарками”, якою я читав у Львівській Політехніці 14-го березня. Нажаль, через технічні проблеми з проектором мені не вдалося показати все, що я планував. Однак я сподіваюся, що зможу включити цю частину у іншу свою лекцію про системне адміністрування.

Якщо ви, проглядаючи презентацію, натиснете S, то побачете speaker notes, які частково зможуть допомогти вам згадати, про що йшла мова.

Повнорозмірна версія презентації.

Презентація з лекції “Роздуми про критичне мислення”

Всім привіт!

Викладаю презентацію до лекції “Роздуми про критичне меслення”, якою ми відкривали цикл наших лекцій у Львівській Політехніці 1-го лютого.

Якщо ви, проглядаючи презентацію, натиснете S, то побачете speaker notes, які частково зможуть допомогти вам згадати, про що йшла мова.

Повнорозмірна версія презентації.

Эффективное разрешение проблем

 

Заметки с тренинга Саши Орлова и Славы Панкратова.
Для заинтересовавшихся: http://www.stratoplan.ru/free/tools/

Содержание:

Будьте конструктивны

 

Признаки конструктива:

  • Своевременность
  • Обсуждается с тем, с кем можно решить
  • Приводятся данные и факты
  • Цель: решить проблему, а не человека
Четыре причины, почему люди чего-то не делают:

  • Нечёткая цель — что требуется-то?
  • Не умеют — надо ли научить?
  • Не могут — позволяют ли время/условия?
  • Не хотят — почему могут не хотеть?

4 фазы решения конфликта/проблемы

1. Подготовка

  • Определите проблему
  • Поставьте цель
  • Запланируйте подход
  • Решите, когда обсудить проблему
Подробнее
  • Определите проблему
    • Каковы мои причины чтобы ее решить?
    • Мое видение проблемы?
  • Поставьте цель
    • Чего я хочу достичь в результате конфронтации?
  • Решите, стоит ли связываться
    • Если не решать, то что будет не так?
    • Это важно для моей работы?
  • Определите время и место. Слушать невозможно, когда:
    • Вы находитесь в состоянии стресса / Под давлением времени
    • На вас «напали»
    • В плохом физическом состоянии
    • Вы привыкли сразу говорить
    • Вы не уважаете собеседника
  • Определите подход
    • Говорите от первого лица
    • Заранее продумайте фразы. Порепетируйте.
    • Будьте объективны. Факты и данные.

План подготовки

  1. В чем проблема?
    • Как я это вижу:
    • Как остальные могут это видеть:
  2. Моя цель? Чего я хочу достичь в результате конфронтации?
  3. Стоит ли связываться?
  4. Где и когда обсудить проблему?
  5. Как я опишу проблему (словами «о себе»)?
  6. Данные и факты?

2. Проблема

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

Ключевые практики при обсуждении:

  1. Говорить от себя и в позитивном ключе
  2. Описывать проблему с точки зрения, как она влияет на работу.
  3. Подчеркивать, что заинтересованы в обоюдовыгодном решении.
  4. Спросить точку зрения другой стороны на проблему.
  5. Слушать эффективно (задавать открытые вопросы, уточнять, повторять своими словами, записывать)
  6. Подвести итог по проблеме

3. Решение

  • Попросите предложить решения
  • Рассмотрите варианты решения; выберите одно
  • Зафиксируйте договоренность
Подробнее
  • Перед переговорами: убедитесь, что есть общее понимание проблемы
  • Попросите предложить решения
  • Слушайте
  • Объясните свое решение
  • Рассмотрите другие варианты
    • Выпишите причины каждой стороны
    • Отметьте пункты согласия и несогласия – это будет чеклист для других вариантов
    • Спросите: «Как вы думаете, мы рассмотрели все варианты»?
  • Выберите решение и задокументируйте его:
    • Что будет сделано, индикаторы, список действий, ресурсы

Ключевые практики при выработке решения:

  1. Просить предложить возможные решения.
  2. Слушать и пытаться понять
  3. Предлагать свои решения
  4. Рассматривать другие варианты
  5. Выбрать решение, которое устраивает обе стороны
  6. Проверить его на реализуемость
  7. Написать письменный план (что будет сделано, индикаторы, список действий, ресурсы)

4. Контроль

  • Установите дату, чтобы обсудить прогресс
  • Проверьте, достигнута ли цель
  • Проверьте, что процесс работает для обеих сторон
Подробнее

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

 

 

Если решение не работает, то возвращаемся к фазе 3

Создание девопс-команды, часть 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. Мы также проводили несколько вполне стандартных интервью, обсуждая резюме кандидата и рассказывая ему о той роли, которую ему предстояло выполнять в команде. Здесь же проходили теоретические собеседования у доски о программировании и алгоритмах.

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

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

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

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

Презентація з лекції “Магія SQL”

Привіт!

Презентація з лекції “Магія SQL”, яку читала Леся Гой у Львівський Політехніці в середу, 15 лютого.

 

Лекція “За лаштунками співбесіди”

Всім привіт!

Викладаю презентацію до лекції “За лаштунками співбесіди”, яку я читав у Львівській Політехніці.

Якщо ви, проглядаючи презентацію, натиснете S, то побачете speaker notes, які частково зможуть допомогти вам згадати, про що йшла мова.

Повнорозмірна версія презентації.