2017-04-16

О Docker Swarm Mode

Вернёмся к нашему рою Докеров. Я уже писал про Docker Swarm. Это когда вы можете запустить кучку Docker Engine в кластере ваших компутеров и управлять контейнерами в этом кластере. Тогда речь шла о Docker Swarm, который представляет собой несколько контейнеров, запущенных в обычном Докере. А с версии Docker Engine 1.12 (июль 2016) у нас появился Swarm Mode, непосредственно внедрённый в Docker Engine. Вот до него-то я и добрался.
Напоминаю. Раньше мы брали самый обыкновенный Докер. Запускали в нём, на каждом физическом узле, контейнер с Consul, чтобы иметь единое распределённое хранилище для метаданных нашего кластера. Потом запускали специальный образ Swarm в виде менеджера (тоже, при необходимости, распределённого) и узлов (воркеров) кластера. Этот Swarm контейнер получал доступ к Docker Engine API на каждом узле, где он запущен, путём проброса сокета Докер демона. И клиенты, включая Docker Compose, общались удалённо теперь уже с менеджером Swarm кластера по тому же самому протоколу и API. Т.е. замена одного Docker Engine на кластер Docker Swarm для клиента и пользователя выглядела почти прозрачной.
Docker pic
Теперь всё по-другому. Теперь Swarm Mode — это особый режим работы Docker Engine. И поддерживается он прямо из коробки. И привносит свои нюансы.
Docker развивается стремительно. Версия 1.12 осталась в далёком прошлом. Так же как и версия 1.13. Теперь Докер нумеруется а-ля Убунту, и текущая версия 17.04.0, соответственно, от апреля 2017 года.
Теперь у нас два Докера: Community Edition и Enterprise Edition. Второй от первого отличается, пока что, лишь наличием платной поддержки. Но, например, Community Edition уже официально не поддерживается под RedHat Enterprise Linux.
Допустим, у нас есть две-три машинки, на которые мы хотим водрузить Docker Engine и объединить их в Swarm.
Для начала нам нужно немного поконфигурировать Докер демон. Учитывая неразбериху со способами инициализации (даже в Убунту проник systemd, а в Дебиане до сих пор можно выбирать между systemd и sysvinit), универсальным способом конфигурирования становится файл /etc/docker/daemon.json
. Об этом способе часто умалчивают. Ну и это JSON, со всеми его прелестями в виде отсутствия комментариев и необходимости не запутаться, где там должен быть массив, а где просто значение.
Нам очень может понадобиться обращаться к нашему кластеру извне, а не только с менеджерских хостов. Поэтому добавляем прослушивание Докер демоном TCP сокета. При этом надо явно добавить и Unix сокет, который прослушивается по умолчанию, иначе локальная команда docker перестанет работать.
"hosts": [
  "unix:///var/run/docker.sock",
  "tcp://0.0.0.0:2375"
]
Если у нас есть локальный Docker Registry, и мы поленились настраивать на нём HTTPS, нам нужно включить этот Registry в список доверенных.
"insecure-registries": [
  "192.168.2.25:5000"
]
Наконец, чтобы как-то пометить наши Докеры, чтобы потом правильно раскидать по ним сервисы, мы можем захотеть указать в конфиге метки. Хоть метки — это ключи и значения, в конфиге они задаются просто как строки.
"labels": [
  "backend=yes",
  "worker=yes"
]
После изменения конфига, очевидно, нужно перезагрузить демон. Например посредством service docker restart.
Теперь можно создавать Swarm. На той машинке, которая станет одним из менеджеров кластера, и с которой вы хотите начать это безобразие, нужно выполнить команду. Внимание, с появлением Swarm Mode у простой и понятной команды docker появилось очень даже много подкоманд. Сейчас будем знакомиться с docker swarm.
$ docker swarm init --advertise-addr 192.168.2.12
Swarm initialized: current node (2epmgc34aa0o7x6z6ho7v8u66) is now a manager.

To add a worker to this swarm, run the following command:

    docker swarm join \
    --token SWMTKN-1-0pcqn90yv70657tpbepxaqjw3et3ihcalpbee8ndzifxg5zncn-5r3zjl1evea481i3mzetnwoff \
    192.168.2.12:2377

To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
Вам нужно указать адрес, по которому данный узел Swarm будет доступен для других узлов. Это довольно важно, если у вас есть несколько интерфейсов, например, для обмена трафиком внутри датацентра.
Узел, на котором мы запустили docker swarm init, становится (первым) менеджером будущего кластера. И нам дают некий токен, который нужен, чтобы подключить к этому кластеру другие узлы.
Команда — не идемпотентна. Попытка проинициализировать Swarm повторно приводит к ошибке.
$ docker swarm init --advertise-addr 192.168.2.12
Error response from daemon: This node is already part of a swarm. Use "docker swarm leave" to leave this swarm and join another one.
С одной стороны, понятно почему. С другой стороны, такая ошибка затрудняет автоматизацию. Можно задать ключ --force-new-cluster true, тогда каждый раз будет создаваться новый кластер, это тоже не то, что хотелось бы. А вот ключа игнорировать наличие кластера — нет.
Итак, у нас, оказывается, есть два типа узлов. Менеджер — с него можно управлять кластером. Менеджеров может быть несколько, они устраивают выборы, определяют кворум и всё такое. По умолчанию узел-менеджер также является и воркером, но можно создать и чистого менеджера. Воркер — запускает на себе контейнеры и всё такое. Чтобы присоединить к кластеру воркера или менеджера, используются разные токены.
Токен для присоединения воркера пишется в выхлопе docker swarm init. Это вариант для человеков. Для автоматизации вам нужно просто вывести токен. Это можно.
$ docker swarm join-token worker -q
SWMTKN-1-0pcqn90yv70657tpbepxaqjw3et3ihcalpbee8ndzifxg5zncn-5r3zjl1evea481i3mzetnwoff
Чтобы присоединить другой Docker Engine к этому Swarm, его нужно присоединить по токену. Нужно ещё указать адрес одного из менеджеров.
$ docker swarm join --token SWMTKN-1-... 192.168.2.12:2377
Эта команда снова не идемпонентна. Попытка присоединиться к кластеру, если узел уже в кластере, приводит к ошибке.
Узлы кластера общаются между собой по кучке портов. TCP порт 2377 — обращение к менеджерам. TCP и UDP порт 7946 — обмен метаданными между узлами. UDP порт 4789 — overlay сеть между узлами. А если мы собираемся использовать зашифрованный overlay, нужно разрешить ещё и протокол 50 (ESP). Но вроде как дополнительно шифровать overlay не очень нужно, ибо, если верить документации, весь трафик между узлами и так шифруется.
Чтобы разобраться с узлами кластера у нас добавилось семейство команд docker node. Например, можно узнать, сколько у нас узлов в кластере и каково их здоровье.
$ DOCKER_HOST=tcp://192.168.2.12:2375 docker node ls
ID                           HOSTNAME  STATUS  AVAILABILITY  MANAGER STATUS
5qt2all7nm1sapczihel6crn7 *  docker2   Ready   Active        Leader
tbojo6bwq3p9rzxf1gzni1ig6    docker1   Ready   Active
Это команды, которые работают только в Swarm Mode, и работают только на узлах-менеджерах. Но мы не зря разрешали удалённый доступ к Docker Engine. Можно выполнить команды удалённо, указав адрес менеджера в переменной окружения DOCKER_HOST.
Swarm workers
Docker Swarm у нас вроде готов. Попробуем взять docker-compose.yml и развернуть его.
$ DOCKER_HOST=tcp://192.168.2.12:2375 docker-compose up

Compose does not use swarm mode to deploy services to multiple nodes in a swarm. All containers will be scheduled on the current node.

To deploy your application across the swarm, use `docker stack deploy`.
Что?
Ну да. Swarm Mode — это вам не старый добрый Swarm на контейнерах. Swarm Mode не совместим ни с чем, кроме себя самого. А Docker Compose теперь пригоден только для запуска кучки связанных контейнеров на одном хосте (локально).
Вместо docker run у нас теперь docker service create. Вместо кучи других команд, которые работают только на одном Докере, у нас теперь целая куча команд docker service, работающих в Swarm Mode.
Сервисы в Docker Swarm — это немножко покруче просто контейнеров, запущенных через docker run. Это, в общем-то, сервисы в понимании Docker Compose. Можно крутить их количество в кластере с помощью docker service scale. Можно смотреть, на каких узлах кластера сервис развёрнут: docker service ps. А самое клёвое, можно на лету менять настройки сервисов, например, проброшенные порты, с помощью docker service update.
Но мы же не хотим забрасывать наши любимые и тщательно выверенные docker-compose.yml? Не заменять же их шелловыми скриптами с docker service? Слава хипстерам, создатели Докера на нас не забили, и у нас есть docker stack.
Тут всё странно. Стек — это множество сервисов. docker stack deploy разворачивает это множество в Swarm согласно описанию в формате Distributed Application Bundles. А получить этот DAB файл (который на самом деле JSON) из docker-compose.yml можно с помощью docker-compose. Зачем ещё один формат?
Но docker stack deploy умеет работать и с docker-compose.yml.
$ DOCKER_HOST=tcp://192.168.2.12:2375 \
docker stack deploy --compose-file docker-compose.yml ${PROJECT}
Тут надо явно указать название стека, который вы разворачиваете. В Docker Compose это называлось проектом и по умолчанию бралось из имени текущего каталога.
Но и docker-compose.yml тут должен быть не простой. Он должен быть версии 3 или выше (сейчас крайняя версия 3.2).
Основное отличие версии 3 от старой доброй версии 2 — свойство deploy у каждого сервиса. docker-compose это свойство игнорирует, а docker stack deploy как раз использует.
В deploy как раз и указываются некоторые штуки, влияющие на то, как сервис воткнётся в Swarm. Можно ограничить узлы, на которых будет запущен сервис. Можно задать режим развёртывания.
version: '3'

services:

  nginx:
    image: nginx
    deploy:
      placement:
        constraints:
          - 'engine.labels.frontent == yes'
      mode: replicated      # maybe 'global' is better here
    ports:
      - '80:80'
    networks:
      - frontend

  worker:
    image: worker
    deploy:
      placement:
        constraints:
          - 'engine.labels.worker == yes'
      mode: replicated
    networks:
      - frontend

networks:
  frontend:
deploy.placement.constraint — это ограничения. engine.labels.* — это метки, что мы задали в daemon.json, т.е. метки Docker Engine. Есть ещё метки узлов. Они навешиваются через docker node update, который нужно выполнить, соответственно, на менеджере кластера. Опять неудобно для автоматизации, нужно ходить на менеджера, но знать имена всех остальных узлов. Метки узлов доступны для проверки как node.labels.*. Синтаксис ограничений, по сравнению со старым Swarm, изменился.
deploy.mode — это режим развёртывания. Пока их два. replicated — это по умолчанию. Сервисов будет запущено столько, сколько скажете сразу при создании, либо до скольки отмасштабируете через docker service scale. И размазаны их контейнеры будут по кластеру ровным слоем, учитывая ограничения, конечно. global — будет запущен ровно один (не более) сервис на каждом узле кластера, учитывая ограничения.
Сети, указанные в docker-compose.yml здесь по умолчанию будут overlay. Т.е. будут спокойно работать между узлами кластера.
Swarm services
С сетью всё вообще очень интересно. Давным-давно, как вы помните, нужно было проставлять linkи между контейнерами, и имя линка появлялось в /etc/hosts. Теперь внутри Docker Engine у нас есть DNS сервер. Linkи не нужны, достаточно, чтобы сервисы были в одной сети. А одна сеть на docker-compose.yml и так формируется по умолчанию. Имена сервисов резолвятся в IP адреса в этих внутренних сетях. А если сервисов отмасштабировано несколько экземпляров, то одно доменное имя будет резолвится на несколько IP адресов. Обычный round robin DNS. И всё это справедливо для нынешнего Docker Compose.
В Swarm Mode пошли чуть дальше. Теперь каждому сервису выдаётся один виртуальный IP (VIP). Доменное имя сервиса резолвится в этот один единственный VIP. А трафик на этот VIP уже магическим образом распределяется между актуальными контейнерами (уже со своими IP). Понятно, зачем это надо. В зависимости от нагрузки на узлы кластера, может потребоваться более тонкая балансировка, чем простой round robin. Но при желании можно вернуться на старое поведение, без VIP, а с множеством IP адресов на одно доменное имя сервиса.
Swarm Service VIP
Серьёзные изменения произошли в публикации портов. Синтаксис остался прежним. А вот смысл теперь совсем другой.
Раньше, когда мы публиковали порт, это означало, что Docker Engine на том хосте, где запущен контейнер с данным сервисом, начинал слушать указанный порт и пробрасывать соединения в контейнер. Но мы не можем точно контролировать, на каком узле будет запущен сервис. В результате нам либо нужно запускать сервисов заведомо столько, сколько узлов в кластере, убеждаться, что они запустились действительно на всех узлах, и использовать внешний балансер. Ну, по сути, делать то, что теперь нам гарантирует deploy.mode = global. Либо наоборот, внедрять балансер, например, HAProxy, в виде сервиса, прибивать его, с помощью ограничений, к определённому узлу, весь внешний трафик направлять на этот узел, а балансировать уже внутри Докера.
Теперь этих мучений во многих случаях можно избежать. Потому что в Swarm Mode есть Ingress Routing Mesh. Если вы публикуете порт в каком-то сервисе, этот порт начинает слушаться на всех узлах кластера. И принимать внешний трафик можно на любом узле кластера. Даже том, где контейнер с данным сервисом в данный момент не запущен. Swarm магическим образом всё это дело смаршрутизирует и сбалансирует до нужного контейнера. Круто? Круто.
Но есть нюансы. Так как эти меши, это, по сути, трансляция адресов, ваше приложение в контейнере видит не реальный IP адрес клиента, а некий адрес во внутренней сети Докера.
Если вам нужно доставить IP адрес клиента до вашего сервиса, у вас есть два пути. Либо мы снова добавляем внешний балансер, и пусть он каким-то образом внедряет IP адрес клиента. В случае HTTP это может быть дополнительный заголовок X-Forwarded-For. Для других протоколов можно использовать HAProxy Proxy protocol. Либо можно отключить этот меш для данного сервиса, и использовать обычный проброс портов, работающий только на одном хосте. Это должно хорошо работать для global сервисов.
Чтобы можно было указать режим публикации портов, синтаксис всё-таки изменился. Можно воспользоваться возможностью обновлять сервисы.
$ docker service update ${PROJECT}_nginx --publish-add mode=host,target=80,published=80
А можно сразу прописать новый хитрый синтаксис в docker-compose.yml.
ports:
  - target: 80
    published: 80
    protocol: tcp
    mode: host
Последний вариант требует версии compose файла аж 3.2 и будет работать только в только-только релизящемся Docker Engine 17.4.0.
Mesh with external balancer
Ну что ж. Docker Swarm Mode — состоявшийся факт. Оно не совместимо с предыдущим Swarm, который, тем не менее, продолжает поддерживаться.
Создание Swarm кластера существенно упростилось. Хотя не очень удачные неидемпотентные команды и необходимость копирования токенов, не сильно помогают в автоматизации развёртывания.
Появилось оооочень много новых команд docker. Старые команды тоже остались, но они не будут работать со Swarm Mode.
Docker Compose сократили до локального инструмента. Вместо него предлагают использовать новые команды docker, в частности docker stack deploy. Однако, весьма полная совместимость на уровне compose файлов осталась.
Mesh роутинг и VIP здорово упрощают развёртывание и разработку в типовых случаях (http микросервисы?). В сложных случаях без явного балансировщика всё равно не обойтись, либо внешнего, либо внутри Swarm.

2017-04-09

О CodeFest 2017

Снова случился CodeFest. И я снова собирался на него не поехать. Настолько, что собрался даже на DUMP в Ёбург. Там совершенно убойная программа на секции Science вырисовывается. Точнее, собрался на оба: и CodeFest, и DUMP. Даже попытался пробиться в докладчики DUMPа, чтобы немного сэкономить. На CodeFest-то бесполезно пытаться докладчиком, ведь я не работаю в яндексах, мейлру, двагисах да бадах. Но в результате я побывал на CodeFest, и на DUMP уже никаких сил нет. Сильно много общения, видимо.
CodeFest logo
В этот раз удалось погулять по Новосибирску. По центру. Было мокро, холодно, грязно и ветренно. Как обычно в это время в Сибири. Делать в центре Новосибирска совершенно нечего. Разве что сфотографироваться на фоне задницы памятника Ленину. Гулять надо по Академгородку. Ну и летом надо обязательно сгонять в новосибирский зоопарк. К стыду своему я там ни разу не был. На карте он выглядит чудовищно громадным.
Посмотрели «Призрака в доспехах» в IMAX. Фильм годен, даже для любителей оригинального аниме. Хотя, конечно, получилась типичная голливудская поделка. IMAX и 3D — к чёрту.
GiS city
Конференцию открывал Marko Berković аж из самого GitHub. Говорил про корпоративную культуру. Как они в ГитХабе отказываются от почты в пользу репозиториев и чатиков. Как они админят всё через чатики с Hubot.
Конечно, принимать совместные решения, редактируя документ в репозитории, и принимая правки через пулреквесты, — замечательно. Это действительно эффективнее, чем почтовая переписка. Но вот что мне в пулреквестах никогда не нравилось. Изменения кода и прочих текстов — под управлением системы контроля версий, в данном случае Git. А пулреквесты, а также связанные с ними обсуждения, — где-то совершенно сбоку, в какой-то БД какой-то проприетарной системы под названием GitHub. Причём, как показал опыл GitLab, удалить эту БД может любой достаточно опытный админ. Я всё жду, когда пулреквесты станут частью самого репозитория, тоже под контролем версий. Кто запилит нужный экстеншен к Гиту или Меркуриалу?
Ну вот, хотел посмотреть, какие доклады я отметил звёздочками. А официальное приложение CodeFest начало падать даже у меня, на Android 6.0.1. Так что, господа организаторы, дело не в том, под какие версии Андроида делали приложение, а в кривых ручках компании Allmax, чей логотип гордо красуется при запуске приложения. А может, во всём виноват React Native.
xSQL
Костя Осипов заменил Дорофеева, собрав полный зал, ещё и с хвостами в коридоре. Я не влез, но полностью доклад поддерживаю. Все эти SQL, NoSQL, NewSQL — это всё об одном и том же, только с разных сторон. А самого Костю мы поймали на афтепати. Разговор был про жизнь, бизнес и всё такое... Но что было на афтепати, останется на афтепати.
Кстати, похоже, это первый тренд конференции: NoSQL и SQL, радость в слиянии. Но я его как-то не заметил, ибо для меня это года два как совершенно ясная тема.
Макса Дорофеева не было. По официальной версии дырка в его расписании для CodeFest не совпала с самим CodeFest в этом году. Зато был конкурс мемасиков, и даже мой хороший знакомый выиграл книжку с автографом. Зато все докладчики, как могли, пытались заменить Дорофеева. Костя Осипов собрал полный зал, Павел Мочалкин рассуждал об устройстве человеческого мозга, Никита Прокопов рисовал слайды «вручную», Фёдор Овчинников сказал слово «жопа» со сцены, впрочем, лишь один раз.
человек-снежинка
Виктор Грищенко очень мило рассказал, как добавив чуток схемы, точнее формального описания грамматики, и таким образом сведя JSON к регулярной грамматике, можно заметно ускорить и стабилизировать парсинг этого самого JSON, в частности в JavaScript, фактически заменив стандартный парсер регулярным выражением. Немного увлекательного матана с неоднозначными практическими выводами.
На этом докладе я понял, что обладаю талантом задавать вопросы из очень неприятной для докладчика категории. Есть такие вопросы, которые очень тщательно обходятся в самом докладе, потому что обнажают недостатки предлагаемого решения и даже могут поставить под сомнение ценность доклада в целом. Хорошие докладчики заранее знают об этих недостатках и готовят ответы на подобные вопросы. Вот я на такие заготовленные ответы и нарывался :)
Второй тренд конференции: протоколы взаимодействия, схема/типизированность или её отсутствие, попытки заменить HTTP и JSON.
Вот и Игорь Кашкута рассказал, как они используют Protobuf поверх голого TCP или WebSocket для общения мобилок с сервером. Казалось бы, Protobuf — это такая жутко строго типизированная штука, которая создаёт код для клиента и сервера, и эти клиенты и сервера должны быть одинаковых версий. Это не SOLIDно. Но ребята из Badoo воспользовались тем, что любое поле структуры, объявленное в Protobuf, вполне себе может быть необязательным. И у них сложился вполне расширяемый и гибкий протокол, работающий через строго типизированный Protobuf.
Пионер
Третий тренд конференции: машинное обучение. Да, оно везде. Уже есть, а будет ещё больше. И пусть мой коллега утверждает, что на Курсере задачки посложнее того машинного обучения, про внедрение которого рассказывали на CodeFest. Это всё дело наживное. Да и не крутостью алгоритмов меряется достигаемый результат.
Иван Бондаренко как раз рассказал, как они обучали машинки распознаванию адресов-телефонов на сайтах компаний. Это у них такая хитрая штука в 2ГИС, чтобы оперативно выяснять, что эти самые адреса-телефоны внезапно изменились. А ещё получившийся ПиоNER успешно потрошит описания лекарств или номенклатуру автомобильных шин.
RTB
Четвёртый тренд конференции: RTB. Ну может, и не тренд, кажется, про RTB больше говорили в прошлом году. А в этом году про RTB, кажется, был вообще только один доклад. Но, имхо, это был настолько замечательный доклад, что вполне достоин обозначить тренд.
Максим Пугачев рассказал про SaaS платформу для RTB от IPONWEB. Первая половина доклада была посвящена обзору RTB как явлению рынка, и какие технические вызовы оно бросает. Это был самое краткое, но объемлющее определение RTB, что я слышал. Браво!
Отрадно слышать, что такая технически сложная штука как RTB, ушла таки в облака. И многие, кто хочет свой RTB, перестали ваять его на коленке. Впрочем, знающие люди говорят, что IPONWEB всё же дорого, и свои костылики обходятся дешевле, если, конечно, знать, где их взять.
Оперный театр
Павел Мочалкин обычно закрывает конференцию. Охлаждает энтузиазм, чтобы все технари не бросились внедрять услышанное с понедельника. В этот раз он решил всех опохмелить утром второго дня. Ну и заодно утешить, что обученные машинки не отберут у нас работу. Потому что мы все такие творческие и уникальные.
Тут обозначился ещё один тренд конференции. Правда, я прошёл почти мимо него. Но между докладами и после весьма много обсуждали. Бирюзовые организации. Где сотрудники обладают достаточной свободой и правом действовать самостоятельно ради общего блага (организации). Самоорганизуются.
Протокол
Никита Прокопов удивил. Снова поднял тему протоколов. Но рассказал вовсе не о том, что было заявлено в описании доклада. По крайней мере я главным увидел другое. Он поднял проблему синхронизации. Данных. Между множеством клиентов и сервером. В исторической и технической перспективе. Про то, как от синхронизации состояния перешли к пересылке событий и их упорядочиванию. Но и это не даёт окончательного решения.
Вообще большинство докладов строилось по одной схеме. Вот тема. Для тех, кто не в теме, вот вам введение для чайников разной степени кипячения, на полдоклада. А вот вам наш крутой продукт, который посвящён этой теме. Либо какое-то частное решение. Либо просто похвастаться хотим. Покупайте наших слонов.
А вот у Никиты получилось хорошо. По-инженерному. Проблему поднял. Всех заставил задуматься. А решения не предложил. Потому что его нет :)
Снова про xSQL. Дмитрий Долгов рассказал про jsonb в PostgreSQL. Удивительно, но в конце прошлого года у нас появился стандарт на JSON в SQL. Продвигаемый, вроде, Oracle. Какой-то странно закрытый. Который скоро будет поддерживать PostgreSQL.
А потом были бенчмарки JSONов в Постгресе, Монге и Мускуле. Постгрес, конечно же, победил. Хотя для тестирования наконец-то взяли не ноутбук Олега Бартунова, а серваки в Амазоне.
Тестировали с YCSB, блин. Ну почему я до сих пор не родил ничего получше, чем этот синхронный ява-монстр, неприспособленный для создания нормальной распределённой нагрузки?
Упоминали контейнеры, Docker, Kubernetes. В той же Lamoda. Пусть это будет ещё одним трендом конференции. Хотя я этого наелся по работе столько, что уже не воспринимаю как откровение. Похоже, это просто стало стандартом. Используем докеры там, где можем.
Resource management
Послушал единственный менеджерский доклад. Дмитрий Плетнев подробнейше рассказал про ресурсный менеджмент. У аутсорсных компаний есть ресурсы. Человеки. Которые что-то умеют и чего-то хотят. И заказчикам нужны эти ресурсы, их часы. Надо свести одних с другими, чтобы никто не страдал. Нужно, чтобы сотрудники были заняты, но не перетруждались, и не простаивали. Нужно, чтобы сотрудними делали то, что они умеют хорошо, но и чтобы развивались.
Очень много чего нужно. И следить за продажами, чтобы тормозить их, когда нет свободных ресурсов. И знать и отслеживать, кто где находится, чем занимается, чего хочет, чем недоволен, куда хочет двигаться.
У них всё получилось. Причём не взрывом мозга у одного директора по ресурсам. Удалось распределить обязанности между менеджерами по ресурсам, на каждом пуле ресурсов. И это в компании из 70 человек. А я вот хорошо знаю человека, который несколько лет в одиночку всё это разруливал в компании, где работает более 200 человек.
Дмитрий задал залу вопрос: Кто проводит у себя стажировки? Потому что стажёры — это очень лояльный и дешёвый ресурс. Из порядка 600 человек в зале руку подняли лишь человек пять. Что? Я думал что в ИТ только те, кому совсем-совсем не надо расти, не проводят стажировок. По крайней мере в Омске все, кому нужны люди, это делают. Оказалось, что Омск — не показатель.
HoloLens
Снова немного машобуча, а на самом деле даже матана, было в докладе Дениса Баталова. В роли слонов выступали некоторые продукты Амазона, включая Amazon Kinesis. Теперь их SQL по потокам данных умеет искать аномалии с помощью леса случайных разбивок.
Andrea Di Persio рассказывал про Go и микросервисы, сдабривая это всё терминами вроде Domain Driven Design. То ли потому, что было на английском, то ли одно из двух, но мне было скучно. Как-то ни про Go не рассказал, ни про микросервисы. Оставлю лишь одну ссылочку для дальнейшего изучения: Prometheus.
Сергей Звягин здорово рассказал про виртуальную, дополненную и другие виды реальности. И продемонстрировал HoloLens. Это такой Project Tango на голове, или сильно прокачанные Google Glass.
Запомните эти жесты. Надо смотреть мимо собеседника, куда-то вдаль. Потом сложить пальцы в щёпоть на вытянутой руке, и резко разжать эту щёпоть (сказав «вах»). Этим вы вызовете меню HoloLens. Потом нужно слегда поводить головой, прицеливаясь в нужный пункт меню. И, наконец, протянуть руку с воображаемой мышкой, и дважды кликнуть этой мышкой. Так вы выберете нужный пункт меню. Со стороны это выглядит неимоверно смешно, даже если у вас на голове хайтековая штуковина за несколько тысяч долларов. Повеселите друзей.
Почему-то на вопрос, что они собираются с такими штуковинами делать, эти ребята-энтузиасты отвечают, что просто следят за тенденциями, но ничего конкретного не пишут. Похоже, рано ещё программистам сюда соваться. Надо контент делать. То же 360° видео. А потом уже захочется сей контент сделать более интерактивным.
Guesture
На закуску участникам подарили Фёдора Овчинникова. Айтишники его плохо знают. Потому что он — создатель сети пиццерий «Додо Пицца». Фёдор — за максимальную открытость. Он кидал клич за идеями по «рефакторингу» их информационной системы. Он, не стесняясь, сообщал о потере 8 миллионов рублей (при обороте за 2016 год более 2.5 миллиардов), просил помощи. И помощь пришла. Любопытно, что Фёдор сказал, что причиной ошибки, и основой решения было одно и тоже. Доверие сотрудникам. Да, та самая бирюзовая организация. Сами напортачили, сами и исправили. Никого не наказали.
Кстати, про информационную систему. Я много раз слышал, что «Додо Пицца» — компания-киборг. Что все процессы внутри компании проходят через информационную систему. Что сама суть компании — эта система, а вовсе не изготовление пиццы. Только сейчас, из первых уст, до меня дошёл смысл этого. «Додо Пицца» — это не компания, которая автоматизировала всё, вплоть до рецептуры теста. «Додо Пицца» — это компания, которая была создана вокруг информационной системы, которая развивалась и росла вместе с компанией. Информационная система не была внедрена в бизнес. Это бизнес вырос на скелете информационной системы. Мне кажется, ещё никто так не делал раньше. Тем интересней следить за экспериментом.
Додо Пицца
В этом году на конференции было как-то мало знакомых лиц. Из Омской компании, где более 200 человек, приехал только один. Где вся эта туча омичей, что значились зарегистрировавшимися? Кто все эти люди вокруг? Поколение сменилось? Хорошо это или плохо?
Резюмирую.
  • SQL никуда не денется, в разных вариантах будет проникать в NoSQL и NewSQL.
  • Протоколы и взаимодействие всё ещё интересны, HTML и JSON хочется чем-то заменить.
  • Машинное обучение уже здесь и сейчас, возможны наколенные применения даже на малых задачах и данных.
  • RTB уже рутина.
  • Микросервисы уже рутина.
  • Контейнеры и Docker уже рутина, но можно поспорить, каким инструментом с ними удобнее обращаться.
  • Виртуальные и прочие реальности всё ещё слишком нишевы, чтобы для них требовалось массово писать софт.
  • Организации мечтают стать бирюзовыми, чтобы сотрудники сами всё делали.