В течение последних нескольких лет в Интернете постоянно ведуться дискуссии о роли, которую играет DevOps. Может показаться, что это становится утомительным, но тот факт, что обсуждение DevOps все еще продолжается, говорит сам за себя: есть еще нерешенные вопросы. И эти проблемы заключаются в общении между бизнесом и инженерами DevOps. Мы в Core 24/7 умеем находить баланс между этими командами и предлагаем девопс услуги, которые вы можете заказать здесь. А теперь к сути.
Люди, которые говорят о Development Operations часто имеют свое собственное определение того, что это слово вообще значит. В какой-то момент оказывается, что стейкхолдеры проекта не понимают друг друга настолько, что совсем перестают понимать зачем им вообще нужен DevOps.
В этой статье мы не будем вступать в споры об определениях. Вместо этого мы сосредоточимся на эволюции ИТ-процессов, на том, что компании могут получить от внедрения DevOps, что это означает для DevOps-инженеров и как мы можем преодолеть разрыв между бизнесами и DevOps специалистами.
Оглядываясь назад на путь, который мы прошли с нашими клиентами, мы видим как изменились бизнес-требования за последние несколько лет. Мы оказываем услуги по сопровождению сложных информационных систем, и поначалу наши клиенты больше всего хотели, чтобы мы сделали их сайты отказоустойчивыми. Сейчас запросы стали кардинально другими. В то время самыми важными вещами были стабильность, масштабируемость и отказоустойчивость среды разработки. Теперь одинаково важна отказоустойчивость среды разработки и систем развертывания.
Крупные компании столкнулись с изменением ценностей: стабильная среда разработки стала так же важна, как и стабильная производственная среда.
Чтобы лучше понять, как мы к этому пришли и как изменился менталитет всей сферы, давайте кратко пройдемся по истории разработки программного обеспечения.
Немного истории разработки программного обеспечения
Эволюцию принципов разработки программного обеспечения можно условно разделить на четыре этапа. Важно отметить, что поставка ПО существовала на всех этапах, хотя ответственные за нее лица менялись на протяжении всей ее эволюции.
Мэйнфреймы: 1960–1980-е гг.
Характерные черты этого этапа: С момента появления компьютеров и примерно до 1985 г. компании разрабатывали программное обеспечение исключительно для внутреннего пользования. Небольшие группы разработчиков поставляли программное обеспечение с довольно ограниченной функциональностью, адаптированное к требованиям конкретной компании или гос организации, где оно будет использоваться. Эта ограниченная функциональность может быть предназначена для отправки людей на Луну, но по сравнению с современными сервисами у нее не так много вариантов использования за пределами той узкой задачи ради которой код был написан.
Пользователи: Сотрудники компании, в которой было разработано программное обеспечение. В те времена количество пользователей ПО также было очень ограниченным — например, 3 астронавта «Appolo» или 20 человек, которые рассчитывали государственный бюджет, или 100 человек, которые обрабатывали результаты переписи населения.
Распространение ПО: через физические носители и мэйнфреймы. Компании должны были изготовить перфокарты, затем поместить их в компьютер, и примерно через 10 минут программа была готова к использованию. Технически за доставку программного обеспечения отвечал человек, вводивший данные на перфокарты. Если разработчик допускал ошибку, ее исправление занимало много времени, потому что для этого требовалось переписывать и отлаживать код, изготавливать новые перфокарты и снова вставлять их в машины. Все это занимало дни работы. Таким образом, ошибки имели очень негативные последствия, а иногда даже могли привести к катастрофе.
На этом этапе ИТ как отдельной сферы бизнеса еще не существовало. В Википедии перечислены только четыре компании по разработке программного обеспечения, основанные в 1975 году. Одной из них была Microsoft, но и та тогда была очень маленькой и нишевой компанией.
ПК и ООП: 1980–1990-е гг.
Ситуация начала меняться примерно в 1985 году, когда персональные компьютеры стали набирать популярность: Apple Computer, Inc. начала производство Apple II в 1977 году, IBM PC был выпущен в 1981 году, а чуть раньше значительную популярность приобрели мини компьютеры DEC.
Характерные черты этого этапа: Разработка ПО превращалась в отдельную сферу бизнеса. Количество пользователей выросло, и это сделало возможным создание коммерческого программного обеспечения.
В 1979 году, например, была представлена первая программа для работы с электронными таблицами под названием VisiCalc. Он взял на себя некоторые вычислительные задачи, ранее выполнявшиеся бухгалтером (эта роль теперь передана Excel). До этого бухгалтер заносил цифры в большую таблицу на бумаге и производил расчеты по разным формулам. Если аналитик спрашивал, что изменится, если выручка в третьем квартале будет вдвое выше, бухгалтер должен был изменить одно значение и проводить все расчеты заново, при этом на бумаге.
Пользователи: Другие компании. VisiCalc полностью изменил компьютерную индустрию. Теперь программное обеспечение разрабатывалось для массового рынка, а не для определенной группы пользователей со специфическими требованиями. Например, экономисты и аналитики начали покупать компьютеры, чтобы использовать электронные таблицы.
Поскольку потенциальных пользователей было больше, а программное обеспечение можно было продавать как частным лицам, так и компаниям, разработчикам приходилось выяснять, как заставить свое ПО работать на большую пользовательскую базу и как создавать такое сложное программное обеспечение в целом.
Растущее число пользователей потребовало расширения функционала. Это также требовало расширения команд разработки — пары умелых разработчиков уже было недостаточно. Для работы над сложным программным продуктом требовалась команда от 100 до 500 человек.
Во время этого этапа стали ясны две вещи. Во-первых, если вы увеличите количество разработчиков в команде в четыре раза, это не значит, что вы получите результат в четыре раза быстрее. Во-вторых, есть и другие возможные решения проблемы масштабирования.
Популярным способом справиться с растущей сложностью программного обеспечения было объектно-ориентированное программирование (ООП). Идея заключалась в том, что если взять большое приложение, такое как Microsoft Excel, и разбить его на отдельные объекты, команды разработчиков могли работать над ними независимо друг от друга. Разделив продукт на части по функциональным элементам, можно было масштабировать и, как следствие, ускорить общую разработку продукта.
Обоснование использования ООП очень похоже на обоснование использования микросервисов в наше время. Однако на этом этапе мы по-прежнему упаковывали приложения в один файл (файл .exe во времена господства Microsoft DOS, а затем и Windows).
Распространение программного обеспечения: Появляются физические носители. На том этапе, когда программы, как продукт, стали производиться массово, процесс доставки состоял из записи ПО на дискеты, маркировки их наклейками, упаковки в коробки и отправки их пользователям по всему миру. Кроме того, необходимо было свести к минимуму количество дефектных дискет. Ведь если мы производим дискеты в Америке, доставляем их в Россию и только потом обнаруживаем, что половина из них бракованная, это означает огромные убытки для бизнеса, а также риск потерять клиента навсегда.
Цикл разработки программного обеспечения был ужасно долгим, ведь каждый этап длился несколько месяцев:
● планирование — 12 месяцев
● разработка — 24 месяца
● тестирование — 12 месяцев
● деливери— 12 месяцев
Новые версии ПО выходили раз в несколько лет, поэтому пространства для ошибок не было.
Однако основным фактором риска было то, что вы не могли получить обратную связь от пользователей на протяжении всего цикла разработки.
Только представьте у нас есть идея ИТ-продукта, мы проводим тесты и решаем, что пользователям может понравиться наш продукт. Но мы не можем быть уверены, что это удастся. Можно писать код в течение двух лет, а затем попросить группу бухгалтеров установить нашу программу (например, новую версию Excel) и опробовать её. И это единственное, что можно сделать, чтобы протестировать наш продукт. Вполне может оказаться, наш “Убийца Excel” никому не сдался, и мы потратили впустую целых два года разработки.
Или может получиться так- люди покупают наше программное обеспечение, но оно глючит и не работает должным образом — и поскольку на этом этапе приложения все еще являются физическими продуктами, которые поставляются в коробках, которые вы можете вернуть в магазин, пользователи могут легко вернуть наш продукт и никогда больше не покупать наши продукты.
Agile: 2001 - 2008 гг.
Следующий этап наступил с внедрением Интернета в массы в 2000-х годах.
Характерные черты этого этапа: ИТ-бизнесы уходили в Интернет, но браузеры еще мало что могли.
Microsoft создала Internet Explorer, который бесплатно предоставлялся всем пользователям Windows. Огромное количество людей теперь могло получить доступ к Интернету. Тем не менее Microsoft намеренно не оптимизировала Internet Explorer для использования динамических функций, чтобы защитить свое программное обеспечение от конкуренции — например, браузерных приложений и браузера Netscape. Таким образом, Интернет в основном использовался для загрузки файлов, но этого было достаточно, чтобы бизнес переехал туда.
Распространение ПО: теперь пользователи могут получать дистрибутивы программного обеспечения из Интернета.
Это позволило гораздо чаще выпускать обновления и новые версии ПО — раз в несколько месяцев. Компаниям больше не нужно было записывать программное обеспечение на дискеты или компакт-диски, потому что пользователи могли загружать обновления из Интернета, а разработчики могли позволить себе делать больше ошибок.
Рисков для бизнеса стало намного меньше, поскольку появилась возможность поддерживать ПО с помощью обновлений, фиксов и новых версий.
Agile, как подход к разработке ПО, появился примерно в то же время, поэтому на этом этапе было издано несколько книг по гибкой разработке ПО и экстремальному программированию, которые до сих пор считаются основой основ IT-менеджмента: например, Extreme Programming Explained: Embrace Change, а также Refactoring. Improving the Design of Existing Code and Test-Driven Development.
Основная идея была во внедрении Интернета, который существенно сократил цикл разработки и позволил выпускать новые версии ПО примерно каждые 6 месяцев.
Цикл разработки ПО в начале 2000-х выглядел примерно так:
● планирование — 2 месяца
● разработка — 6–12 месяцев
● тестирование — 1–3 месяца
● деливери— несколько недель.
Во-первых, тщательное тестирование было не так важно, как раньше. Даже если 10 процентов пользователей могли столкнуться с ошибками, было проще выпустить патч, чем тратить год на то, чтобы убедиться, что программа работает должным образом абсолютно для всех. Таким образом, компании также могли быстрее проверять свои гипотезы (хотя в данном случае быстрее означало 6–12 месяцев).
Более того, тратя меньше средств на тестирование и тщательное планирование, компании могут сократить расходы на эти эксперименты. Как раз таки экспериментирование и станет ключевой идеей следующего этапа.
DevOps: 2009– Наше время
Характерные особенности этого этапа: Интернет постепенно появляется везде. Набирают популярность социальные сети и развлекательные приложения, доступ к которым осуществляется исключительно через Интернет. Теперь мы можем реализовать сложную динамическую функциональность, которая запускается в браузере, поэтому предприятия пользуются этой возможностью.
Доставка программного обеспечения: Внедряются облачные сервисы. На предыдущем этапе программное обеспечение устанавливалось на компьютер пользователя, поэтому его нужно было адаптировать к этой среде. Теперь мы можем настроить его на один компьютер — наш сервер в облаке. Это очень удобно потому что сохраняется полный контроль над этим компьютером и над тем, как на нем работают наши приложения. Могут быть некоторые трудности с рендерингом интерфейсов в браузере, но это не настолько существенная проблема по сравнению с проблемами прошлого.
Все это помогает нам ускорить планирование, внедрение и тестирование. Теперь нам не нужно оставаться в неведении месяцами или даже годами, когда дело доходит до того, будет ли реализован наш проект, какие функциональные возможности нужны пользователям и так далее. Обновления ПО возможны практически в режиме реального времени.
Тем не менее в 2006 — 2008 годах программное обеспечение разрабатывалось с использованием той же идеологии — приложение рассматривалось как единое целое. Хотя это уже не был файл .exe, он все же был ближе к монолиту, состоящему из нескольких тесно связанных объектов. Такое программное обеспечение было слишком громоздким, чтобы его можно было быстро адаптироваться к изменяющемуся рынку.
Чтобы решить эту проблему, те же люди, которые принесли нам ООП, также предложили разделить приложения, чтобы ПО состояло из отдельных элементов, которые взаимодействовали друг с другом. Это позволило бы еще больше расширить команды разработчиков, от сотен до тысяч человек, и постоянно дорабатывать новый функционал. Это позволило компаниям больше экспериментировать, проверять гипотезы, адаптироваться к требованиям рынка и поведению конкурентов и продолжать развивать свой бизнес.
В 2009 году мир увидел первую презентацию по объединению Dev и Ops для развертывания кода 80 раз в день. Это единство стало одной из главных ценностей в разработке программного обеспечения. Цикл разработки теперь выглядит совершенно иначе:
● планирование — несколько недель
● разработка — несколько недель
● тестирование — несколько дней
● деливери — несколько минут
Мы можем практически сразу исправлять ошибки и быстро разрабатывать новые гипотезы. Это также был этап, когда был введен термин MVP - Минимально жизнеспособный продукт.
Если в 1970-х годах у разработчиков почти не было права на ошибку, а ПО было практически неизменяемым (вам особо не нужно менять требования каждый раз, когда вы отправляете астронавтов на Луну), то сейчас оно абсолютно динамично. Каждый ожидает найти ошибки в своем программном обеспечении, поэтому мы должны обеспечивать техническую поддержку и иметь команду, которая следит за тем, чтобы ваша система работала правильно, независимо от динамических изменений в ней.
На этом новом этапе впервые в истории ИТ роль доставки программного обеспечения действительно стала ИТ-работой.
До этого специалист, ответственный за поставку программного обеспечения в принципе не считался ИТ-сотрудником. С 1970-х по 1980-е годы эта работа заключалась в простой установке перфокарт в компьютеры, а с 1980-х по 1990-е годы она сводилась к переговорам с производителями компакт-дисков и заботе о логистике. Все это не имело ничего общего с разработкой программного обеспечения или системным администрированием.
Те, кто не очень хорошо знаком с DevOps, часто думают, что «инженер DevOps» — это просто модное новое имя для системного администратора, который больше связан с разработчиками. Но на практике (и в статьях Википедии тоже) DevOps — это методология, которая применяется при разработке программного обеспечения. Однако самое главное не определение, а то, что дает нам DevOps. А DevOps как методология позволяет нам как можно быстрее адаптироваться к меняющемуся рынку и реструктурировать способы разработки программного обеспечения.
Если бизнес не хочет отставать от своих конкурентов, он должен избавиться от длинных циклов разработки с ежемесячными выпусками и вместо этого внедрять DevOps. Трансформация DevOps здесь означает полный переход от разработки к развертыванию на Agile. Вот так доставка программного обеспечения становится частью процесса разработки и превращается в ИТ-должность.
Поскольку доставка программного обеспечения связана с обслуживанием серверов и инфраструктуры, кажется, что эта работа лучше подходит для тех, у кого есть сисадминский опыт. Но в этом случае у нас возникают проблемы со связью между DevOps-инженерами и бизнесом. Это особенно актуально, если мы говорим об администраторах, которые принимают участие в трансформации DevOps и пытаются удовлетворить потребности бизнеса, который хочет быть более гибким.
У большинства сисадминов, отвечающих за отказоустойчивость, есть мантра: «Работает-не трогай» Но в новых, динамичных условиях современного мира бизнесу необходимо (независимо от возможных сбоев):
● пройти путь от идеи до развернутого продукта за минимальное время;
● проверить максимальное количество гипотез за короткое время;
● минимизировать влияние ошибок на производство.
Даже если что-то ломается, это не проблема — мы можем откатиться, исправить причину проблемы и развернуть код заново. Лучше быстро оценить шансы нашего продукта на успех, чем инвестировать в то, что не будет пользоваться спросом.
Подход к отказоустойчивости меняется: нам больше не нужно, чтобы текущая версия нашего ПО оставалась стабильной в течение длительного времени — нам просто нужно уменьшить влияние ошибок в текущей версии на производительность всей системы.
Вместо того чтобы следить за стабильностью каждого кусочка кода, мы должны иметь возможность быстро возвращаться к стабильной версии если что-то пошло не так. Это тоже относится к гибкости: ценность даже не в качестве кода развернутого в инфраструктуре, а в способности инфраструктуры быть чрезвычайно адаптивной.
В нашей работе с группой компанией Chocofamily задачей было внедрение современных DevOps технологий с целью создания отказоустойчивой среды разработки. Тесно работая с командой разработчиков, мы смогли создать устойчивую и прозрачную модель которая позволила не только ускорить процессы разработки, но и осуществлять более эффективный мониторинг цифровых продуктов.
