DevOps глазами программиста - как я познакомился с DevOps

Прошло уже много лет с появления термина, но до сих пор можно увидеть и услышать разные вариации на тему того, что же он значит на самом деле. 

Где-то 7 лет назад ко мне на работе подошла начальница и сказала, что у нас в системе появился новый проект – DevOps и теперь мы будем им заниматься. Я впервые это слышал на тот момент и задал вполне резонный вопрос – как это повлияет на мой рабочий день и мои обязанности? 

Мне сказали, что раньше я писал код под проекты, фиксил баги, запускал код на сервера, поддерживал SQL Server и IIS, настраивал репликацию, отвечал на звонки даже в выходные, если сервера упали и т.д. Теперь я буду писать код под проекты, фиксить баги, запускать код на сервера, поддерживать SQL Server и IIS, настраивать репликацию и отвечать на звонки даже в выходные, если упадут сервера. Просто теперь если я работаю на проект, я должен билить время на этот проекта, а если занимаюсь всем остальным, то должен билить время на проект Maintenance. Разница - и у них разный бюджет, я могу заниматься поддержкой только определенное количество часов в месяц. 

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

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

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

С появлением термина стали больше обсуждать эти процессы. До этого чаще обсуждалась разработка, а как потом код будет запускаться и обслуживаться – а как-нибудь, что там сложного. Но в реальности есть сложности и если программисты или администраторы будут брать на себя ещё и запуск с обслуживанием, то это вешалка.

Единственная проблема, которая была в нашем подходе, когда я делал абсолютно все – программист должен обладать слишком большим количеством знаний – уметь хорошо программировать, знать не просто SQL сервер, а его администрирование, репликацию и т.д. В мои задачи входила поддержка прокси серверов, а это Linux сервера, доставка кода на сервера приложений – а это скрипты на каком-либо скриптовом языке + умение писать Bash скрипты, потому что в те времена PowerShell не было, поэтому все автоматизировалось через Cygwin. 

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

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

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

Откуда пошло выражение – тыж программист? На заре ИТ программисты сами могли собирать компьютеры, устанавливать и настраивать различный софт, менять картриджи и писать код. Они и сейчас это могут делать, но зачем? Зачем программисту менять картридж или менять накрывшийся жесткий диск, когда можно разделить эти обязанности с кем-то, кто будет это делать даже лучше. И так появились администраторы. Им не нужно писать код и знать паттерны программирования, но они имеют супер опыт поддержки техники, они знают все внутренности системников – что совместимо и с чем. Как программист я думаю только о том, что у моего компьютера есть процессор, 32 гигабайта оперативки и SSD диск на террабайт – все, мне больше ничего не нужно знать и забивать себе голову этими вещами. 

Появление термина положительно сказалось и на качестве. Как я уже сказал – начали обсуждать проблему запуска и обслуживания, начали искать эффективные решения и готовые рецепты. Уже нет такого отношения, как это была раньше – и так сойдёт. Как у программистов есть паттерны программирования, так и у DevOps стали появляться свои паттерны работы, которые стали частью CI,CD. 

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

Мониторинг и раньше был неплохим, тут развитие есть, но я бы не стал его связывать с появлением термина DevOps, но мониторинг стали относить к DevOps. Не везде, но у меня как раз мониторинг уходил в DevOps обязанности. Тут я говорю не про мониторинг оборудования, это все ещё работа администраторов. Я говорю о мониторинга ошибок приложения и производительности. 

---

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