Хабрахабр

От сисадмина к человеку

Первые обычно хвастаются тем, что используют Chef/Puppet/Ansible/Docker c 200X года, вторые считают, что DevOps либо изжил себя и ведет к NoOps, либо что «я завернул всё в контейнер, а дальше как пойдёт». На DevOps есть по крайней мере два устоявшихся взгляда — со стороны системных администраторов и со стороны разработчиков.

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

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

В основе материала — расшифровка доклада Александра osminog Титова с нашей октябрьской конференции DevOops 2017.

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

Мой рассказ — про мой карьерный путь, но я буду снабжать его интересными советами и своими умозаключениями. Я работаю в компании Экспресс 42. Я отделяю роль системного администратора от некоторого человеческого состояния. У него броское название «От сисадмина к человеку». DevOps двигает нас к тому, чтобы быть не просто исполнителями, а творцами новых цифровых продуктов и прочего.

Начинал я как системный администратор, когда учился в университете. Поскольку мой рассказ базируется на моем опыте, чуть-чуть расскажу о себе. Далее я работал в социальных сетях сonnect.ua и fakultet.ru, потом — техническим директором в компании Оверсан-Скалакси. Работал в ночную смену, затем стал работать в дневную, затем дослужился до ведущего системного администратора. Необходимость в облачных хостингах в России возникла только сейчас. Это была одна из первых попыток запустить в России облачный хостинг, как оказалось, очень ранняя попытка. В те времена этого вообще никто не понимал, поэтому продавать его было очень сложно. Мы только поняли, как ими пользоваться, поняли, что это гибкие ресурсы, что для них надо по-другому писать приложения и так далее.

В Qik я реально ощутил пользу от концепции DevOps, потому что за два месяца мы сделали продукт, который вырос с 0 до 5 млн пользователей. Потом я работал в стартапе Qik из Кремниевой долины, офис разработки у которого был здесь, в России. Затем нас купил Skype, и мы начали туда интегрироваться, а также интегрировать туда наработки в сфере DevOps, потому что в Skype его не было. Если в Оверсан-Скалакси я с точки зрения сервиса ощутил, что DevOps нужен и люди должны понимать, что такое DevOps, чтобы пользоваться облачным хостингом, то в Qik я ощутил это как системный администратор и как руководитель отдела системных администраторов. Вроде пришел в компанию, где около 40 человек, а через несколько лет работаешь в крупной компании, в которой 100 тысяч сотрудников. А потом Skype купил Microsoft. Это был очень интересный опыт.

Эта идея зародилась еще в Оверсан-Скалакси, она и движет мной. В итоге я не нашел, куда дальше двигаться в этих компаниях, и мы с коллегами открыли компанию Экспресс 42, которая несет DevOps в массы. Я — организатор DevOpsDays Moscow и московских DevOps-митапов. Кроме всего прочего, я очень болею за 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. В итоге я административно запретил использовать FreeBSD в компании, несмотря на то что саму систему я искренне люблю и уважаю, особенно люблю OpenBSD. Я, несмотря на мой сисадминский опыт, не мог разобраться, а если я не мог, то как разработчик должен был понять, как деплоить через эту CI-систему? Но через неделю среди Linux-серверов снова начали, как мухоморчики, появляться FreeBSD-серверы.

Если технология им нравится, они пытаются воткнуть ее везде.
В Оверсан-Скалакси мы придумали такой термин, как write-only-конфигурации и скрипты. DevOps-сисадмины, так же как и разработчики, думают, что технологии — это самое важное, без них ничего не сделать. Это когда человек смог написать, но никто не смог прочитать.

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

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

DevOps для бизнеса

Какой-нибудь ваш топовый менеджер съездил на какую-то бизнес-конференцию, например, в долину, где ему сказали, что если у вас нету Docker, какого-нибудь continuous integration (CI) и еще чего-то, то вы не можете считаться технологической компанией. Еще один путь появления DevOps — со стороны бизнеса. Ребята начинают разбираться, и дальше происходят смешанные сценарии, о которых говорилось выше: DevOps-разработчик, DevOps-сисадмин, и это всё приводит к каше, которую не разберешь. Менеджер возвращается, собирает сотрудников и читает слова из блокнота: DevOps, Docker, Concourse CI.

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

От энтерпрайза к Agile

Во-первых, с точки зрения бизнеса, у нас происходит такой перелом: мы уходим от энтерпрайза, который реализует монументальные проекты по переводу из точки А в точку Б самого бизнеса (например, пятилетняя стратегия с целью захватить 70% рынка)…

Смысл Agile не в том, чтобы быть гибким, а в том, что пункт А известен, а Б — нет. … и приходим к миру Agile. Потому что ни мы, ни бизнес не привыкли с этим работать. И это самое крышесносное, что может произойти. И вы не знаете, что делать, но мир и бизнес становятся такими, и к этому нужно привыкать. Представьте себе, что вы не знаете, что произойдет через неделю или через две недели, что к вам пришел руководитель и сказал: «Так, ты попробуй мне добыть то, чего не может быть, запиши себе название, чтобы в спешке не забыть». И все эти практики, вроде Agile, Scrum, Kanban — не про то, как с этим жить.

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

NoSQL не круче SQL, более того, на состояние 3-4 года назад он гораздо хуже SQL. DevOps появляется не потому, что кому-то из вас должно стать удобно, и не потому, что надо применять более крутые технологии. И мы помним плачевное состояние MongoDB 4 года назад, когда она вообще не была базой данных. SQL-базы разрабатывались 20 лет, а NoSQL-базы — 1 год.

Если вы разработчик, вы пишете код и сразу же пишете тесты, обертку для Kubernetes или просто Docker-контейнер, как он должен работать в продакшне.
DevOps — это то же самое, что и раньше, только теперь мы делаем всё одновременно. Потому что многие разработчики в предыдущую эпоху этим не занимались: компилятор откомпилировал, а то, что там запустилось и начало работать в контейнере приложений — это уже дело десятое. И при этом вы должны выполнить одно минимальное условие — запустить этот код. И потом запуливаете это все в Delivery Pipeline, Jenkins, TeamCity или еще во что-нибудь. Одновременно пишете метрики, логи, которые должны собираться. Здесь разработчик начинает писать не просто алгоритмы, а продукт целиком. Это кардинальное отличие разработчика в корпорации от разработчика в технологической компании.

История DevOps

Здесь самое время обратиться к истории DevOps. Как все это возникло? Я жил этим, постоянно читал новости, следил за исторической цепочкой, как это все появлялось. А сейчас мне разные люди из разных годов рассказывают разные версии о том, что такое DevOps и как он возник. И мне кажется важным вернуться к истокам.

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

На тот момент это был фурор и взрыв. В 2009 году Джон Алспоу и Пол Хаммонд сделали доклад про совместную работу внутри Flickr и про то, как они деливерятся 10 раз в день. А Патрик Дебуа подсмотрел этот доклад и придумал термин DevOps, организовал мировое сообщество для того, чтобы развивать эту практику дальше.

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

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

Как же применять DevOps?

Очень важно при применении DevOps реально осознать, что вы делаете цифровой продукт и компании важен time to market (TTM).

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

С этим у нас большие проблемы. Еще одна неочевидная и очень важная вещь, о которой мы все забываем — это организация накопления и обмена знаниями внутри команды и между командами. Надо рассказывать о том, что не готово, проверять гипотезы, надо быть открытым тому, чтобы кто-то рассказал, что не готово. Мы не любим делиться чем-то, что, например, еще не готово, а это ключ к тому, чтобы DevOps существовал. Потому что мы привыкли, что, например, если сисадмины потестили какую-то прикольную вещь, пришли, рассказали, им отвечают: «Не, а как это в продакшне работает, вы что потестили?»

А правильно будет сказать: «Ребята, смотрите! Сисадмины, понимая, что где-то они не поняли, где-то не потестили, уходят, закрываются, а эти знания пропадают, и шаг вперед мы не делаем. Вы подумали об этом? Вы очень круто все сделали, классная работа, но есть один вопрос, который очень хочется вам задать: как это будет работать в продакшне? А в случае с классическим нашим российским подходом «да не-не, всё фигня» они уходят с мыслью «зачем нам это делать, если нам все отказали». Если вы в следующий раз покажете нам, как эту функцию в продакшне реализовать, то будет очень классно!»
Они уже уходят с заданием. Мы не делимся друг с другом, потому что не уверены, что это не будет признано очевидным или не столь хардкорным, как кажется, и так далее. И это большая проблема внутри DevOps-сообщества.

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

Разработчик в DevOps

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

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

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

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

Инфраструктурный инженер

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

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

Но это high level, и я не уверен, что такие инженеры на рынке присутствуют в виде инфраструктурных инженеров. Инфраструктурный инженер проектирует платформу как продукт, знает, как быть product owner, что такое дизайн-мышление, знает, как собрать требования с разработчиков.

Тестировщик-технолог

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

Релиз-менеджер/СТО

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

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

Вы постоянно получаете информацию о том, как ваш код проходит через delivery pipeline, и, используя эту информацию, вносите изменения.
Здесь важно, что код идет по процессу поставки вправо, а информация о том, как он идет — влево.

Нельзя говорить, что вот эта штука — Петина проблема, так как он будет перегружен, не сможет справляться со сложностью той информации, которая поступает от кода, и в итоге вы получите плохо работающий continuous delivery pipeline. Главное, что нужно донести друг до друга, до разработчиков, до всех — что вся эта инфраструктура есть общий инструмент (как гит), который совершенствуется всеми.

У некоторых людей (релиз-менеджер или CTO) есть знания и опыт обо всем — они удерживают картину целиком. Внутри такой схемы нужно делить не ответственность, а знания и опыт. У других есть знания и опыт о системе оркестрации ресурсов, у третьих — о базе данных и так далее, и это разные команды, разные люди, которые занимают здесь место и при этом несут ответственность за всю инфраструктурную платформу целиком.

Есть некоторый базовый уровень — уровень оркестрации (выделения) ресурсов и разных низкоуровневых инфраструктурных сервисов.
Это разделение на уровни мы в Экспресс 42 называем концепцией base-service-app. Есть сервисный уровень: разные базы данных, load balancers, мониторинги, логирования, CI-движки (TeamCity как движок или Jenkins как движок). Знаниями и опытом здесь больше обладают инфраструктурные инженеры. Опять же сошлюсь на доклад Николая Рыжикова, он отлично показал, как это все вместе работает и как реализовать CI поверх Kubernetes. Есть уровень приложения, который собирает эти уровни вместе через всякие API, функции и так далее.

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

И здесь я ссылаюсь на слова Алана Кея, который как-то в интервью Хабру сказал потрясающую фразу: «Компьютеры можно сравнить с музыкальными инструментами, их музыка — это идеи».
Соответственно технологии, которые у нас есть, должны быть включены в процессы, которые создают идею (идея улучшения продукта, идея по изменениям процессов, идея создания нового продукта). У каждого из слоев технологий есть свои процессы, которые должны быть выстроены. д.), для того чтобы играть музыку, а не разбивать гитару об голову соседа. Это очень важно.

Компании, которые практикуют DevOps, должны организовать внутри себя площадку и некоторую систему ценностей, которые позволят обсуждать, какие идеи мы создаем при помощи тех технологий, которые используем, и насколько мы используем эти технологии (Kubernetes, Prometheus, Docker и т.

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

За последние 3-4 года изменилось уже немало технологий и стандартов использования, их даже фиксировать бесполезно в документах, только в головах у людей. Текущий момент отличается от старого энтерпрайз-момента тем, что там стандарты были прибиты гвоздями, а сейчас они меняются непрерывно.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть