На DevOps есть по крайней мере два устоявшихся взгляда — со стороны системных администраторов и со стороны разработчиков. Первые обычно хвастаются тем, что используют Chef/Puppet/Ansible/Docker c 200X года, вторые считают, что DevOps либо изжил себя и ведет к NoOps, либо что «я завернул всё в контейнер, а дальше как пойдёт».
Бизнес при этом читает про DevOps в статьях и надеется, что ребята снизу разберутся, что с ним делать. При этом самого DevOps не происходит, бизнес не похож на Google, компания не становится бирюзовой, люди не создают новых подходов для проверки гипотез в мире.
Эта статья — про DevOps как систему. Как он помогает бизнесу, какие компетенции со стороны инженеров должны появиться для DevOps, какие бизнес-задачи можно решать DevOps-методом производства программного обеспечения, а также какие ошибки возможны на пути к DevOps-производству и как их избежать или купировать. Как, в конце концов, инженеру стать Человеком и быть в этом мире творцом, как для этого построить карьерный путь и как начать смотреть на технологии по-человечески.
В основе материала — расшифровка доклада Александра osminog Титова с нашей октябрьской конференции DevOops 2017.
Для тех же, кому привычней смотреть доклады с конференций в записи, прикладываем видео.
Я работаю в компании Экспресс 42. Мой рассказ — про мой карьерный путь, но я буду снабжать его интересными советами и своими умозаключениями. У него броское название «От сисадмина к человеку». Я отделяю роль системного администратора от некоторого человеческого состояния. DevOps двигает нас к тому, чтобы быть не просто исполнителями, а творцами новых цифровых продуктов и прочего.
Поскольку мой рассказ базируется на моем опыте, чуть-чуть расскажу о себе. Начинал я как системный администратор, когда учился в университете. Работал в ночную смену, затем стал работать в дневную, затем дослужился до ведущего системного администратора. Далее я работал в социальных сетях сonnect.ua и fakultet.ru, потом — техническим директором в компании Оверсан-Скалакси. Это была одна из первых попыток запустить в России облачный хостинг, как оказалось, очень ранняя попытка. Необходимость в облачных хостингах в России возникла только сейчас. Мы только поняли, как ими пользоваться, поняли, что это гибкие ресурсы, что для них надо по-другому писать приложения и так далее. В те времена этого вообще никто не понимал, поэтому продавать его было очень сложно.
Потом я работал в стартапе Qik из Кремниевой долины, офис разработки у которого был здесь, в России. В Qik я реально ощутил пользу от концепции DevOps, потому что за два месяца мы сделали продукт, который вырос с 0 до 5 млн пользователей. Если в Оверсан-Скалакси я с точки зрения сервиса ощутил, что DevOps нужен и люди должны понимать, что такое DevOps, чтобы пользоваться облачным хостингом, то в Qik я ощутил это как системный администратор и как руководитель отдела системных администраторов. Затем нас купил Skype, и мы начали туда интегрироваться, а также интегрировать туда наработки в сфере DevOps, потому что в Skype его не было. А потом Skype купил Microsoft. Вроде пришел в компанию, где около 40 человек, а через несколько лет работаешь в крупной компании, в которой 100 тысяч сотрудников. Это был очень интересный опыт.
В итоге я не нашел, куда дальше двигаться в этих компаниях, и мы с коллегами открыли компанию Экспресс 42, которая несет DevOps в массы. Эта идея зародилась еще в Оверсан-Скалакси, она и движет мной. Кроме всего прочего, я очень болею за DevOps-сообщество в России. Я — организатор DevOpsDays Moscow и московских DevOps-митапов.
Меня с давних времен заботило, что использование Ansible может быть плохим или хорошим. Инструмент в целом ничего не решает. Вы можете использовать Docker, Kubernetes, поставить самый последний Prometheus, но при этом то, что вы делаете, не будет отличаться от того, что есть у людей, использующих bash-скрипты. Я постараюсь ответить, почему так получается. Во многом этот ответ лежит внутри нас, поэтому статья и называется так. Сисадмин думает, как бы ему bash-скриптов понаписать, а человек думает немного по-другому.
Как в компании появляется DevOps?
DevOps разработчика
Существует несколько путей появления DevOps в компании. Один из этих путей — это когда разработчики, устав просить сисадминов что-то сделать и наслушавшись про DevOps, пытаются его внедрять. Но при этом у них своеобразное понимание DevOps. Они думают, что могут использовать любые технологии, обернуть все в Docker-контейнер и отправить системным администраторам, но совсем не задумываются о том, как их код будет работать в продакшне. Они не изменили ничего у себя в голове, чтобы перейти на DevOps, но при этом начинают использовать новые технологии.
Я много видел таких компаний. К них приходишь — у них четыре отдела разработки. Каждый отдел пишет свой микросервис, в каждом отделе есть своя база данных. У кого-то Redis, у кого-то PostgreSQL, у кого-то PostgreSQL и MySQL одновременно. И они это сопровождают, пока базы данных не разрастаются до таких размеров, что они дальше не могут.
В этот момент всё начинает сыпаться и разваливаться, и возникают ужасающие последствия. Это зоопарк технологий, с которым непонятно, что делать. Причем особенность разработчика в том, что он решает проблему, притаскивая новую библиотеку. Я думаю, тем, кто работает с Node.js-разработчиками, это знакомо. Когда Node.js-разработчики видят, что база данных работает плохо, они могут перескочить с PostgreSQL такой-то версии на другую, или присобачить какое-нибудь расширение, или начать использовать какой-нибудь JSONB. В итоге возникает жуткое состояние архитектуры, но в целом их все устраивает. Приложение сложно управляется, не разберешь, что там происходит, у него низкая устойчивость, оно постоянно падает. В ответ на падающее приложение разработчики втыкают туда еще что-нибудь, и всё дальше продолжает падать, и в итоге вообще ничего не понятно.
DevOps сисадмина
Есть такое явление, как DevOps-сисадмин. Обычно это очень мощные ребята, хорошо себя зарекомендовавшие. Они приходят и говорят: «Ребят, так жить нельзя, мы эту текучку задолбались тянуть, Мы сейчас все автоматизируем, сделаем delivery pipeline, такой сладкий, прекрасный, хорошо работающий. Мы прекрасно знаем, как приложение должно работать в продакшне. Гораздо лучше, чем вот эти олухи, пишущие на Node.js. И мы знаем, что надо использовать, чтобы все было прекрасно».
Я несколько раз сталкивался с тем, что такие люди строили DevOps на FreeBSD. Получалась закрытая система, которую они сами написали, и только они понимали, как она работает. Я, несмотря на мой сисадминский опыт, не мог разобраться, а если я не мог, то как разработчик должен был понять, как деплоить через эту CI-систему? В итоге я административно запретил использовать FreeBSD в компании, несмотря на то что саму систему я искренне люблю и уважаю, особенно люблю OpenBSD. Но через неделю среди Linux-серверов снова начали, как мухоморчики, появляться FreeBSD-серверы.
DevOps-сисадмины, так же как и разработчики, думают, что технологии — это самое важное, без них ничего не сделать. Если технология им нравится, они пытаются воткнуть ее везде.
В Оверсан-Скалакси мы придумали такой термин, как write-only-конфигурации и скрипты. Это когда человек смог написать, но никто не смог прочитать.
При этом сисадмины продолжают в мыле что-то чинить. Ты к нему приходишь и предлагаешь помощь, а он тебе трехэтажным матом что-то выдает. Ты ничего не понимаешь, потому что надо разобраться, что у него понаделано. Ну а если разработчик придет и скажет, например, что ему нужна отказоустойчивая база данных? Ему этим трехэтажным матом что-то выдадут, он сядет и не поймет, что с этим делать. Все, приплыли, разработчики и сисадмины при этом не общаются. Хотя внутри используется все самое современное, навороченное.
Отсюда появилось традиционное представление о сисадминах: это такой многорукий человек, который что-то делает, но вообще не разберешь, что именно. Кстати, большинство HR сейчас ищут именно таких. Я вам могу сказать, что нахождение такого человека в компании не избавит вас от проблем на 100%.
DevOps для бизнеса
Еще один путь появления DevOps — со стороны бизнеса. Какой-нибудь ваш топовый менеджер съездил на какую-то бизнес-конференцию, например, в долину, где ему сказали, что если у вас нету Docker, какого-нибудь continuous integration (CI) и еще чего-то, то вы не можете считаться технологической компанией. Менеджер возвращается, собирает сотрудников и читает слова из блокнота: DevOps, Docker, Concourse CI. Ребята начинают разбираться, и дальше происходят смешанные сценарии, о которых говорилось выше: DevOps-разработчик, DevOps-сисадмин, и это всё приводит к каше, которую не разберешь.
На самом деле, я постоянно вижу такие ситуации. Почему так происходит: приходишь на конференцию, у всех рациональный, нормальный взгляд — потом идешь в окопы, в производство, а там треш и угар? То есть все всё понимают, но почему-то не работают. У меня есть гипотеза, что все понимают какую-то частичку, не все целиком. И поэтому сейчас я попытаюсь целостно рассказать про DevOps.
От энтерпрайза к Agile
Во-первых, с точки зрения бизнеса, у нас происходит такой перелом: мы уходим от энтерпрайза, который реализует монументальные проекты по переводу из точки А в точку Б самого бизнеса (например, пятилетняя стратегия с целью захватить 70% рынка)…
… и приходим к миру Agile. Смысл Agile не в том, чтобы быть гибким, а в том, что пункт А известен, а Б — нет. И это самое крышесносное, что может произойти. Потому что ни мы, ни бизнес не привыкли с этим работать. Представьте себе, что вы не знаете, что произойдет через неделю или через две недели, что к вам пришел руководитель и сказал: «Так, ты попробуй мне добыть то, чего не может быть, запиши себе название, чтобы в спешке не забыть». И вы не знаете, что делать, но мир и бизнес становятся такими, и к этому нужно привыкать. И все эти практики, вроде Agile, Scrum, Kanban — не про то, как с этим жить.
Мы переходим от уклада энтерпрайз-компаний и корпораций к укладу технологических. С нами на рынке начинает взаимодействовать какое-то программное обеспечение. Если раньше с нами взаимодействовали люди, компании, по телефону звонили продажники и так далее, то сейчас, чтоб вызвать такси, заказать пиццу, послушать музыку, мы заходим в приложение. А приложение — это программное обеспечение, которое кем-то должно писаться и непрерывно адаптироваться к рынку. А мы с вами — инженеры и те, кто занимается бизнесом — должны понимать по приложению, что с рынком происходит. И в итоге это двигает нас в сторону DevOps.
DevOps появляется не потому, что кому-то из вас должно стать удобно, и не потому, что надо применять более крутые технологии. NoSQL не круче SQL, более того, на состояние 3-4 года назад он гораздо хуже SQL. SQL-базы разрабатывались 20 лет, а NoSQL-базы — 1 год. И мы помним плачевное состояние MongoDB 4 года назад, когда она вообще не была базой данных.
DevOps — это то же самое, что и раньше, только теперь мы делаем всё одновременно. Если вы разработчик, вы пишете код и сразу же пишете тесты, обертку для Kubernetes или просто Docker-контейнер, как он должен работать в продакшне. И при этом вы должны выполнить одно минимальное условие — запустить этот код. Потому что многие разработчики в предыдущую эпоху этим не занимались: компилятор откомпилировал, а то, что там запустилось и начало работать в контейнере приложений — это уже дело десятое. Одновременно пишете метрики, логи, которые должны собираться. И потом запуливаете это все в Delivery Pipeline, Jenkins, TeamCity или еще во что-нибудь. Это кардинальное отличие разработчика в корпорации от разработчика в технологической компании. Здесь разработчик начинает писать не просто алгоритмы, а продукт целиком.
История DevOps
Здесь самое время обратиться к истории DevOps. Как все это возникло? Я жил этим, постоянно читал новости, следил за исторической цепочкой, как это все появлялось. А сейчас мне разные люди из разных годов рассказывают разные версии о том, что такое DevOps и как он возник. И мне кажется важным вернуться к истокам.
В 2003 году Бен Трейнор в Google создает команду SRE. Google — это первая в мире серьезная цифровая компания. Уже в 2003 году они столкнулись с проблемой, что классическим способом, к которому привыкли все разработчики ПО, не получится сделать то, что они хотят. И они сделали новшество, введя команду SRE, и с тех пор развивают эту практику.
В 2009 году Джон Алспоу и Пол Хаммонд сделали доклад про совместную работу внутри Flickr и про то, как они деливерятся 10 раз в день. На тот момент это был фурор и взрыв. А Патрик Дебуа подсмотрел этот доклад и придумал термин DevOps, организовал мировое сообщество для того, чтобы развивать эту практику дальше.
Появились технологические компании, у которых возникла необходимость в том, чтобы быстро деливериться. Старые подходы не подходили, и они стали придумывать новые. И плавненько, естественным образом перекомпоновывались, чтобы у них завелась новая практика создания программного обеспечения.
Мы с вами находимся в очень тяжелой ситуации, потому что у нас не было этого естественного изменения. К нам приходят такие технологии, когда уже что-то там произошло, а мы еще не знаем, как ими пользоваться. Там люди эволюционно к этому пришли, а нам приходится делать революцию, переосмысливать все это и как-то перекладывать на свою почву.
Как же применять DevOps?
Очень важно при применении DevOps реально осознать, что вы делаете цифровой продукт и компании важен time to market (TTM).
Важно превратить все команды в команды разработки. Уже нет отдельно сисадмина, отдельно разработчика. Потому что те, кого мы называем системными администраторами, пишут то, что называется инфраструктурной платформой, а разработчики пишут то, что называется продуктом, и таким образом они предоставляют друг другу сервис.
Еще одна неочевидная и очень важная вещь, о которой мы все забываем — это организация накопления и обмена знаниями внутри команды и между командами. С этим у нас большие проблемы. Мы не любим делиться чем-то, что, например, еще не готово, а это ключ к тому, чтобы DevOps существовал. Надо рассказывать о том, что не готово, проверять гипотезы, надо быть открытым тому, чтобы кто-то рассказал, что не готово. Потому что мы привыкли, что, например, если сисадмины потестили какую-то прикольную вещь, пришли, рассказали, им отвечают: «Не, а как это в продакшне работает, вы что потестили?»
Сисадмины, понимая, что где-то они не поняли, где-то не потестили, уходят, закрываются, а эти знания пропадают, и шаг вперед мы не делаем. А правильно будет сказать: «Ребята, смотрите! Вы очень круто все сделали, классная работа, но есть один вопрос, который очень хочется вам задать: как это будет работать в продакшне? Вы подумали об этом? Если вы в следующий раз покажете нам, как эту функцию в продакшне реализовать, то будет очень классно!»
Они уже уходят с заданием. А в случае с классическим нашим российским подходом «да не-не, всё фигня» они уходят с мыслью «зачем нам это делать, если нам все отказали». И это большая проблема внутри DevOps-сообщества. Мы не делимся друг с другом, потому что не уверены, что это не будет признано очевидным или не столь хардкорным, как кажется, и так далее.
Я уже слышал от организаторов конференций, что все требуют мегахардкора. Ну может быть, можно сделать не мегахардкор, но так, чтобы человек поделился реальным опытом и чтобы можно было об этом поговорить, это же тоже классно.
Разработчик в DevOps
Разработчик в DevOps пишет не код, а продукт. И это неочевидная вещь, потому что в институтах, курсах, книгах нас как программистов учат писать алгоритмы, а не продукты, учат решать не бизнес-задачу, а алгоритмическую задачу. Это огромная проблема. Очень важно у себя в голове отследить, в какой момент ты решаешь алгоритмическую задачу, а в какой момент — реально бизнес-задачу.
В компании, практикующей DevOps, разработчик сразу думает, как его код будет интегрироваться с другими компонентами. Сразу же начинает коммуницировать по этому поводу. Например, уточнять в чате дорожную карту изменения API, которую он использует, чтобы сверяться. Это начало сотрудничества.
Разработчик имеет представление об архитектуре приложения — это очень важно, так как без понимания, как устроена архитектура, какие есть технологические слои и как они друг с другом взаимодействуют, невозможно думать об интеграции.
Разработчик знает, как код работает в бою, и понимает, что с этим приложением происходит. В моем примере, когда разработчик пишет сразу и код, и Docker-контейнер, и мониторинг, у него должно быть представление о том, как устроена архитектура, как код работает в продакшне и интегрируется в приложение. Те из вас, кто работает системными администраторами или инфраструктурными инженерами, подумайте, как донести до разработчиков эти знания. Ваша задача — рассказать им об этом. Можно нанять консультантов, но лучше самим.
Инфраструктурный инженер
Следующая роль, которая есть в DevOps — это инфраструктурный инженер, который раньше назывался системным администратором. Термин «DevOps-инженер» мне категорически не нравится, потому что DevOps — это общая практика, которая покрывает и разработку, и тестирование, и эксплуатацию. Как я говорил ранее, можно иметь DevOps-инженера, DevOps-команду, самые лучшие технологии, а DevOps при этом не иметь.
Инфраструктурный инженер создает платформу в первую очередь для разработки продукта, но при этом она должна быть удобной для разработчиков. Этот баланс нужно стараться соблюдать.
Инфраструктурный инженер использует несколько слоев абстракции для предоставления сервисов. Например, был хороший доклад Николая Рыжикова про Kubernetes, он там показал, как выделять и использовать несколько слоев абстракции. У него там была идеальная модель, которая применяется на практике. Такую модель можно нарезать на отдельные уровни абстракции. Это делается для того, чтобы снизить сложность решения проблем и интеграции. Когда у вас есть понятные уровни абстракции, вы можете между ними перекидываться и смотреть, где несоответствия. Не надо доверяться слоям абстракции, но они очень полезны для того, чтобы можно было об этом говорить. То есть они должны быть не абсолютом, а полезным инструментом.
Инфраструктурный инженер проектирует платформу как продукт, знает, как быть product owner, что такое дизайн-мышление, знает, как собрать требования с разработчиков. Но это high level, и я не уверен, что такие инженеры на рынке присутствуют в виде инфраструктурных инженеров.
Тестировщик-технолог
Тестировщик тоже немного меняется и становится технологом, который достигает улучшения качества ПО и превращает этот процесс в код.
Релиз-менеджер/СТО
Менеджер держит в голове процесс непрерывной поставки программного обеспечения, управляет ожиданиями бизнеса и техническими возможностями, продюсирует выпуски и релизы. Продюсирует, а не планирует, так как процесс перехода из точки А в точку Б нелинейный, и при таких обстоятельствах планировать он не может.
В итоге они все вместе строят инфраструктурную платформу, которая является инструментом всех: инфраструктурных инженеров, разработчиков, тестировщиков.
Здесь важно, что код идет по процессу поставки вправо, а информация о том, как он идет — влево. Вы постоянно получаете информацию о том, как ваш код проходит через delivery pipeline, и, используя эту информацию, вносите изменения.
Главное, что нужно донести друг до друга, до разработчиков, до всех — что вся эта инфраструктура есть общий инструмент (как гит), который совершенствуется всеми. Нельзя говорить, что вот эта штука — Петина проблема, так как он будет перегружен, не сможет справляться со сложностью той информации, которая поступает от кода, и в итоге вы получите плохо работающий continuous delivery pipeline.
Внутри такой схемы нужно делить не ответственность, а знания и опыт. У некоторых людей (релиз-менеджер или CTO) есть знания и опыт обо всем — они удерживают картину целиком. У других есть знания и опыт о системе оркестрации ресурсов, у третьих — о базе данных и так далее, и это разные команды, разные люди, которые занимают здесь место и при этом несут ответственность за всю инфраструктурную платформу целиком.
Это разделение на уровни мы в Экспресс 42 называем концепцией base-service-app. Есть некоторый базовый уровень — уровень оркестрации (выделения) ресурсов и разных низкоуровневых инфраструктурных сервисов. Знаниями и опытом здесь больше обладают инфраструктурные инженеры. Есть сервисный уровень: разные базы данных, load balancers, мониторинги, логирования, CI-движки (TeamCity как движок или Jenkins как движок). Есть уровень приложения, который собирает эти уровни вместе через всякие API, функции и так далее. Опять же сошлюсь на доклад Николая Рыжикова, он отлично показал, как это все вместе работает и как реализовать CI поверх Kubernetes.
Процессы и технологии крайне важны. У технологий, которые вы используете, кроме них самих, есть способ использования. Например, ножом можно нарезать хлеб, а можно убить человека. Так же и здесь, только в нашем случае всё еще сложнее, еще больше уровней абстракции. Те процессы, которые вы создаете вокруг этого, очень важны. И эти процессы, в принципе, кроме вас внутри компании никто создать не может, потому что они сильно заточены под конкретные приложения. Сейчас в принципе невозможно, чтобы, как раньше, вы наняли консультанта по ITIL, и он вам все процессы поставил. Приложение интернет-банка и Яндекс.Музыки отличаются как небо и земля. Там есть общие принципы, но при этом сам процесс совсем другой.
У каждого из слоев технологий есть свои процессы, которые должны быть выстроены. И здесь я ссылаюсь на слова Алана Кея, который как-то в интервью Хабру сказал потрясающую фразу: «Компьютеры можно сравнить с музыкальными инструментами, их музыка — это идеи».
Соответственно технологии, которые у нас есть, должны быть включены в процессы, которые создают идею (идея улучшения продукта, идея по изменениям процессов, идея создания нового продукта). Это очень важно.
Компании, которые практикуют DevOps, должны организовать внутри себя площадку и некоторую систему ценностей, которые позволят обсуждать, какие идеи мы создаем при помощи тех технологий, которые используем, и насколько мы используем эти технологии (Kubernetes, Prometheus, Docker и т. д.), для того чтобы играть музыку, а не разбивать гитару об голову соседа.
В принципе, DevOps-процесс с точки зрения человека внутри компании должен быть устроен следующим образом. Должны существовать такие организационные единицы, как комитеты, которые собираются из людей, которым важно это обсуждать. Это не должен быть отдел архитектуры или отдел интеграции, либо отдел continuous delivery, либо отдел качества — это должны быть комитеты, которые собираются и обсуждают, как мы сейчас работаем и какие новые идеи создаем на базе наших технологий. Они создают и изменяют способы работы, а на основе этого создают знание, часть которого будет неформальным, и это нормально. Вообще русские люди хорошо знают, как передавать знания метафорами, например, когда механик говорит «дай мне эту хрень». Через сотрудничество и коммуникацию эти знания создаются и вкладываются внутрь способов употребления технологий и самих технологий, и этот стандарт знаний реализуется на технологии.
Текущий момент отличается от старого энтерпрайз-момента тем, что там стандарты были прибиты гвоздями, а сейчас они меняются непрерывно. За последние 3-4 года изменилось уже немало технологий и стандартов использования, их даже фиксировать бесполезно в документах, только в головах у людей.
Если вам понравился этот доклад, приходите на конференцию DevOops 2018: там можно будет не только послушать доклады, но и пообщаться с любым докладчиком в дискуссионной зоне. Конференция пройдёт в Петербурге 14 октября, с первого сентября стоимость билетов увеличится.
