Определението на DevOps е много сложно, затова всяка ситуация налага да стартираме дискусия за него отново. Само в Хабра има хиляди публикации на тази тема. Но ако четете това, вероятно знаете какво е DevOps. Защото аз не знам. Здравейте, аз съм Александър Титов (@), и ще говорим просто за DevOps, като споделя своя опит.
Дълго време се чудех как да направя разказа си полезен, затова тук ще има много въпроси - тези, които си задавам и онези, които задавам на клиентите на нашата компания. Отговаряйки на тези въпроси, разбирането става по-добро. Ще разкажа защо DevOps е полезен според моята гледна точка, какво е то отново според мен и как да разберете, че вървите към DevOps - отново от моята перспектива. Последният пункт ще бъде чрез въпроси. Отговаряйки на тях сами, ще можете да разберете дали вашата компания напредва към DevOps или има проблеми.
Веднъж бях на вълните на сливания и поглъщания. Първоначално работих в малък стартап Qik, който след това беше придобит от малко по-голямата компания Skype, а след това бе закупен и от още по-голямата компания Microsoft. В този момент ми стана достъпно виждането как се трансформира представата за DevOps в различни по размер компании. След това стана интересно да гледам на DevOps от перспектива на пазара, и заедно с колеги организирахме компанията Експрес 42. Вече 6 години плаваме на нея по вълните на пазара.
Освен всичко друго, аз съм един от организаторите на общността DevOps Moscow и организатор на DevOps -Days 2017, но 2018 не организирах. Експрес 42 работи с много компании. Развиваме там DevOps, наблюдаваме как това се случва, извеждаме изводи, анализираме и споделяме своите изводи с всички, учим хората на практиките на DevOps. Общо взето, всячески увеличаваме опита и експертизата в това направление.
Защо DevOps
Първият въпрос, който ни преследва постоянно — защо? Много хора смятат, че DevOps е просто автоматизация или нещо подобно, което вече е било в всяка компания.
— Имахме Continuous Integration — значи, вече имахме DevOps, и защо всичко това е необходимо? Там в чужбина си играят, а на нас ни пречат да работим!
За 9 години развитие на общността и методологията вече стана ясно, че това не са просто маркетингови трикове, но все пак не е напълно ясно защо е нужен. Както при всеки инструмент и процес, DevOps има конкретни цели, които в крайна сметка решава.
Всичко това е свързано с факта, че светът се променя. Той се отдалечава от подхода на предприятие, при който компаниите се насочват веднага към мечтата, както пя нашият питерски класик, от точка А до точка В по определена стратегия с изградената за това структура.
В принципе, в ИТ всичко и трябва да бъде построено по този подход. Тук ИТ се използва изключително за автоматизация на процесите.
Автоматизацията не се променя често, защото когато компанията върви по утъпкания път – какво да се променя? Работи – не го пипай. В момента в света подходите се променят, и този, който се нарича Agile, говори за това, че крайната точка В не е веднага видима.
Когато компанията навлиза на пазара и работи с клиента – тя постоянно изследва пазара и променя крайната точка В. И колкото по-често компанията променя своята посока, толкова по-успешна става, тъй като избира повече пазарни ниши.
Стратегията демонстрира интересна компания, за която научих наскоро. One Box Shave – сервиз за доставка на самобръсначки и принадлежности за бръснене по абонамент в кутия. Те могат да персонализират своята „кутия“ за различни клиенти. Това се реализира с помощта на специален софтуер, който след това изпраща поръчката до корейска фабрика, произвеждаща продукта.
Този продукт беше купен от компания Unilever за 1 млрд. долара. Сега той конкурира с Gillette и е отнел значителна част от потребителите на американския пазар. One Box Shave казват:
– 4 остриета? Наистина? Защо ви е нужно това – това по никакъв начин не подобрява качеството на бръснене. Специално подбраният крем, ароматът и качествената самобръсначка с две остриета решават много повече въпроси, отколкото тези глупави 4 остриета на Gillette! Така ли скоро ще достигнем 10?
Така светът се променя. Unilever заявяват, че разполагат с готина IT-система, която позволява това да се направи. В крайна сметка това изглежда като концепция Time-to-market, за която всеки вече е говорил.
Смисълта на Time-to-market не е в това колко често разгръщаме. Може да разгръщаме често, но цикълът на пускане на новини ще бъде дълъг. Ако тримесечните цикли на пускане се накладат един върху друг, размествани с около седмица, получава се, че компанията сякаш разгръща веднъж седмично. А от идеята до окончателната реализация преминават 3 месеца.
Time-to-market е за минимизиране на времето от идеята до окончателната реализация.
В този случай софтуерът взаимодейства с пазара. Например, в One Box Shave клиентът взаимодейства със сайта. Те нямат продавачи - просто сайт, където посетителят кликва и оставя желания. Съответно, на сайта трябва постоянно да се публикува нещо ново, за да се обновява в съответствие с желанията. Например, в Южна Корея бръсненето е различно от това в Русия и им харесва по-скоро мирисът на моркови и ванилия, а не боровини.
Тъй като се изисква бързо да се сменя съдържанието на сайта, разработката на софтуер доста се променя. Чрез софтуера трябва да разберем какво искат клиентите. Преди разбирахме това по някакви затруднени пътища, например чрез бизнес управление. След това проектирахме, задавахме изисквания в ИТ системата и всичко беше чудесно. Сега е различно - софтуерът се проектира от всички, които са включени в процеса, включително и инженери, тъй като те разбират чрез техническите характеристики как функционира пазара и също така споделят своите прозрения с бизнеса.
Например, в компанията Qik ние неочаквано разбрахме, че на хората много им харесва да качват списъци с контакти на сървера и те ни предоставиха приложение. Първоначално не бяхме мислили за това. В класическа компания всички биха решили, че това е бъг, тъй като в спецификацията не е записано, че това трябва да работи отлично и всъщност е било реализирано на коляно, щяха да изключат функцията и да кажат: „Това не е нужно на никого, най-важното е, че основната функционалност работи“. А технологичната компания в това вижда възможност и започва да променя софтуера в съответствие с това.
През 1968 година проницателният човек Мелвин Конвей формулира следната идея.
Организацията, която създава система, е ограничена от дизайна, който копира структурата на комуникацията в тази организация.
Ако искате да произвеждате системи от различен тип, трябва да имате комуникационна структура, която също е различна. Ако комуникационната ви структура е горноподредена, това няма да ви позволи да изграждате системи, които да осигуряват много висок показател за време до пазара.
Прочетете може да се намери . Той е важен за разбирането на културата или философията на DevOps, тъй като единственото, което основно се променя в DevOps, е структурата на комуникацията между екипите..
От гледна точка на процеса, преди DevOps, всички етапи: анализ, разработка, тестване, експлоатация, протичаха линейно.
В случая с DevOps всички тези процеси протичат едновременно.
Само по този начин може да се изпълни времето до пазара. За хората, които работеха в стария процес, това изглежда доста космически и изобщо не е лесно.
И така, защо е необходим DevOps?
За разработката на цифрови продукти.Ако в компанията ви няма цифров продукт, DevOps не е нужен – това е много важно.
DevOps преодолява ограничението на скоростта в последователната производствена схема на софтуера.При него всички процеси протичат едновременно.
Увеличава се сложността. Когато евангелисти на DevOps говорят, че с него ще стане по-лесно да се пуска софтуер – това е невежество.
С DevOps всичко ще стане само по-сложно.
На конференцията на щанда на Авито можеше да се види какво значи да деплойвате Docker контейнер – нерешима задача. Сложността става непоносима, трябва да жонглирате с много топки едновременно.
DevOps променя напълно процеса и организацията в компанията, по-точно, не DevOps променя, а цифровият продукт. За да се стигне до DevOps, трябва да смените този процес напълно.
Въпроси за специалиста
А как е при вас? Въпросите, които можете да си зададете, работейки в компанията и развивайки се като специалист.
Имате ли стратегия за създаване на цифров продукт? Ако имате – вече е добре. Това означава, че вашата компания се движи в посока DevOps.
Вашата компания вече създава цифров продукт? Това означава, че можете да се издигнете на следващото ниво, занимавайки се с по-интересни неща – отново от гледна точка на DevOps. Казвам го само от тази гледна точка.
Вашата компания ли е един от лидерите на пазара в нишата с цифров продукт? Spotify, Яндекс, Uber — компании, които са на върха на технологичния напредък в момента.
Задайте си тези въпроси и ако на всички отговори сте отговорили отрицателно, може би не трябва да се занимавате с DevOps в тази компания. Но ако темата за DevOps наистина ви интересува, може би... е време да преминете в друга компания? Ако вашата компания иска да се насочи към DevOps, но на всички въпроси сте отговорили „Не“, тя наподобява прекрасния носорог, който никога няма да се промени.
Организация
Както вече споменах, според закона на Конвей в компанията се променя организацията. Ще започна с това, което пречи на DevOps да проникне вътре в компанията именно от гледна точка на организацията.
Проблемът с «колодците»
Английската дума «Silo» е преведена тук на български като «колодец». Същността на този проблем е, че между екипите няма обмен на информация. Всеки екип копае своята експертиза навътре, без да създава обща карта, по която да се ориентира.
Това донякъде напомня на човек, който току-що е пристигнал в Москва и все още не умее да се ориентира по картата на метрото. Москвичите обикновено отлично познават района си, а в цялата Москва се ориентират по картата на метрото. Когато пристигнете в Москва за първи път, нямате това умение и просто сте дезориентирани.
DevOps предлага да преминете през този момент на дезориентация и всички подразделения заедно да изградят обща карта на взаимодействието.
На това пречат два фактора.
Следствие на корпоративната система на управление. Тя е изградена от отделни йерархични «колодци». Например, има определени KPI в компаниите, които поддържат тази система. От друга страна, също така пречат умът на човека, на когото му е трудно да излезе извън пределите на своята експертиза и да се ориентира в цялата система. Това просто е некомфортно. Представете си, че сте в летището в Банкок — там не можете бързо да се ориентирате. В DevOps също е трудно да се ориентирате, затова хората казват, че е нужно да намерите водач, за да стигнете там.
Но най-важното е, че проблемът с «колодците» за инженер, който е овладел духа на DevOps, е прочел Фаулър и куп други книги, се изразява в това, че «колодците» не позволяват да се правят «очевидни» неща. Често след DevOps Moscow се събираме, разговаряме помежду си и хората се оплакват:
— Искахме просто да стартираме CI, а се оказа, че това не е необходимо на управлението.
Това се случва именно заради това, CI и Процес на непрекъсната доставка са на границата на много експертизи. Ако не преодолеете проблема с "кладенците" на организационно ниво, няма да можете да напреднете, без значение какво правите и колко тъжно е.
Всеки участник в процеса в компанията: разработчици на бекенд и фронтенд, тестери, DBA, експлоатация, мрежа, копае в своята посока, а никой не притежава обща карта, освен управителя, който по някакъв начин ги наблюдава и управлява с метода "разделяй и владей".
Хората се състезават за някакви звездички или флажки, всеки копае своята експертиза.
В крайна сметка, когато се появи задачата всичко това да се свърже заедно и да се изгради общ пайплайн, и за звездички и флажки вече не трябва да се състезавате, възниква въпросът - какво да правим всъщност? Трябва да намерим начин да се разберем, а никой не ни е учил как да го направим. Още от училище сме научени: осми клас — уау! — в сравнение със седми клас! Тук е същото.
При вас в компанията е така?
За да проверите това, можете да си зададете следните въпроси.
Използват ли екипите общи инструменти, правят ли принос в измененията на тези общи инструменти?
Колко често екипите се преобразуват — едни специалисти от един екип преминават в друг екип? Именно в DevOps среда това става нормално, защото понякога човек просто не може да разбере с какво се занимава другата област на експертиза. Той преминава в друг отдел, работи там две седмици, за да създаде за себе си карта за ориентация и взаимодействие с този отдел.
Може ли да се създаде комитет за изменение и нещо да се промени? Или за това е нужна силна ръка на най-висшето ръководство и заповед? Напоследък написах във Facebook как една малко известна банка внедрява инструменти чрез заповеди: написали са заповед, внедряваме година, наблюдаваме какво се случва. Това, разбира се, е дълго и тъжно.
Насколко е важно за мениджърите да получават лични достижения, без да се вземат предвид достиженията на компанията?
Ако си отговорите на тези въпроси, ще стане по-ясно дали имате такъв проблем в компанията.
Инфраструктура като код
След като се реши този проблем, първата важна практика, без която е трудно да напреднеш в DevOps, е инфраструктурата като код.
Най-често инфраструктурата като код се възприема така:
— Нека автоматизираме всичко с bash, да се намажеме със скриптове, за да имат администраторите по-малко ръчна работа!
Но това не е така.
Инфраструктурата като код предполага, че IT-системата, с която работите, описвате под формата на код, за да разбирате постоянно нейното състояние.
В сътрудничество с други екипи вие създавате карта под формата на код, която е разбираема за всички и по която можете да се ориентирате и навигирате. Независимо от инструмента—Chef, Ansible, Salt или използването на YAML файлове в Kubernetes—няма значение.
На конференцията колега от 2ГИС разказваше как са направили собствен инструмент за Kubernetes, който описва устройството на отделните системи. За да опишат 500 системи, им трябвал отделен инструмент, който генерира това описание. Когато има това описание, всеки може да се сверява с другия, да следи промените, как да го промени и подобри, какво му липсва.
Съгласете се, отделните bash скриптове обикновено не дават това разбиране. В една от компаниите, в които работих, дори имаше название „write only“-скрипт—когато скриптът е написан, но е невъзможно да се прочете. Мисля, че това също ви е познато.
Инфраструктурата като код е код, който описва актуалното състояние на инфраструктурата.Над този код съвместно работят множество продуктови, инфраструктурни и сервизни екипи и, най-важното, всички те трябва да разберат как този код работи изобщо.
Кодът се поддържа в съответствие с най-добрите практики за работа с код:съвместна разработка, код рецензии, XP-програмиране, тестване, пул реквести, CI за инфраструктурата на кода—всичко това е полезно и може да бъде използвано.
Кодът става общ език за всички инженери.
Промяната на инфраструктурата в кода не отнема много време.Да, и в инфраструктурния код може да има технически дълг. Обикновено екипите се натъкват на него около година и половина след като започват да внедряват „инфраструктурата като код“ под формата на куп скриптове или дори Ansible, който пишат като спагети код, и още bash скриптове хвърлят в купчината!
Важно: ако все още не сте пробвали това нещо, запомнете, че Ansible - не е bash! Внимателно прочетете документацията и проучете какво всъщност пишат за него.
Инфраструктурата като код е разделяне на инфраструктурния код на отделни слоеве.
В нашата компания разграничаваме 3 основни слоя, които са много ясни и простички, но може да има и повече. Можете да погледнете вашия инфраструктурен код и да видите дали имате това условие или не. Ако не са отделени никакви слоеве, ще трябва да отделите време и да рефакторирате малко.
Основен слой е как се настройва ОС, резервни копия и други нискоуровневи неща, например как се разгръща Kubernetes на основно ниво.
Слой на услугите е за услугите, които предоставяте на разработчика: логване като услуга, мониторинг като услуга, база данни като услуга, балансировач като услуга, опашка като услуга, Непрекъсната доставка като услуга - множество услуги, които отделни екипи могат да предоставят на разработката. Всичко това трябва да бъде описано с отделни модули в системата за управление на конфигурацията.
Слой, където се създават приложения и описва как те ще се разгръщат над два предходни слоя.
Контролни въпроси
Имате ли в компанията общ инфраструктурен репозиторий? Контролирате ли техническия дълг в инфраструктурата? Използвате ли практики за разработка в инфраструктурния репозиторий? Разделена ли е вашата инфраструктура на слоеве? Можете ли да се сверите с диаграмата Base-service-APP. Колко сложно е да се направи промяна?
Ако сте се сблъсквали с факта, че внесенето на промени е отнело един и половина дни, това означава, че имате технически дълг и трябва да се заемете с него. Точно сте се натъкнали на капаните на техническия дълг в инфраструктурния код. Помня много истории, когато за да смениш някакъв CCTL, трябва да пренапишеш половината инфраструктурен код, защото креативността и желанието за автоматизация е довело до това, че всичко е заплетено, всичките ръчки са премахнати, и трябва да се рефакторирате.
Непрекъсната доставка
Възможно е да се дефинира дълга с кредит. Първо се появява описание на инфраструктурата, което може да бъде доста основно. Не е необходимо всичко да се описва в детайли, но е нужно основно описание, за да можете да работите с него. В противен случай не е ясно как да се реализира непрекъсната доставка. Всички тези практики се реализират едновременно, когато се стигне до DevOps, но трябва да започнете с разбирането какво имате и как да го управлявате. Това е точно практиката инфраструктура като код.
След като стане ясно какво имате и как да го управлявате, започвате да измисляте как кодът на разработчика да бъде изпратен на продукция възможно най-бързо. Имам предвид заедно с разработчика — помним проблема с „кладенците“, тоест не отделни хора създават идеите, а екипно.
Когато ние с Ивайло Евтухович видяхме първата книга на Джез Хамбла и група автори «Непрекъсната доставка», която излезе през 2009 година, дълго се чудихме как да преведем нейното заглавие на български. Искахме да го преведем като „Постоянна доставка“, но за съжаление го преведохме като „Непрекъсната доставка“. Мисля, че в нашето заглавие има нещо много българско, с упоритост.
Постоянна доставка означава
Кодът, който е в продуктовия репозиториум, винаги може да бъде изтеглен в продукция. Той може да не бъде изтеглен, но винаги е готов за това. Съответно, винаги пишете код с трудно обяснимо чувство за известно безпокойство. То често се появява, когато се внедрява инфраструктурен код. Това чувство за безпокойство трябва да присъства — то предизвиква мозъчни процеси, които позволяват да се пише код по-различно. Това трябва да бъде фиксирано в правилата на разработката.
За да се реализира постоянна доставка, необходим е формат на артефакт, който преминава през инфраструктурната платформа. Ако хвърляте на инфраструктурната платформа различни по формат „отпадъци от жизнената дейност“, то тя става неунифицирана, трудно поддържана, възниква проблем с техническия дълг. Форматът на артефакта трябва да бъде унифициран — това също е колективна задача: трябва да се съберем заедно, да раздвижим мозъците и да измислим този формат.
Артефакт непрекъснато се подобрява и променя под продукционната среда по време на преминаване през доставния pipeline. Когато артефактът преминава през пайплайна, той постоянно се сблъсква с някои предизвикателства, подобни на тези, с които се сблъсква артефактът, който вие пускате в продукция. Ако в класическата разработка това се извършва от системен администратор, който прави разгръщането, то в DevOps процеса това се случва постоянно: тук го тестват с различни тестове, тук — е в Kubernetes клъстър, който е донякъде подобен на продукцията, а тук внезапно започват нагрузъчни тестове.
Това по някакъв начин напомня на играта Пакман — артефактът преминава през определена история. Важно е да се контролира дали кодът наистина следва историята и дали тя е свързана с вашата продукция. Истории от продукцията могат да бъдат вградени в процеса на Непрекъсната Доставка: имаше случаи, когато нещо се провали, сега нека програмираме този сценарий в системата. Всеки път кодът ще минава през този сценарий също, и вие няма да се сблъскате с този проблем следващия път. Ще разберете за него доста по-рано, преди да достигне до вашия клиент.
Различни стратегии за разгръщане. Например, можете да използвате AB тестване или канарски разгръщания, за да 'проучите' кода на различни клиенти, да получите информация как работи кодът и значително по-рано, отколкото той ще бъде пуснат на 100 милиона потребители.
„Постоянно доставяне“ изглежда така.
Процесът на доставка Dev, CI, Test, PreProd, Prod — не е отделна среда, а етапи или станции с неизменни суми, през които преминава вашият артефакт.
Ако имате инфраструктурен код, описан като Base Service APP, той помага да не забравите всички сценарии, и да ги запишете също като код за този артефакт, да напредвате артефакта и да го променяте по време на движението.
Въпроси за самопроверка
Времето от описанието на функцията до пускането в продукция в 95 % от случаите по-малко от седмица ли е? Увеличава ли качеството на артефакта на всеки етап от пайплайна? Има ли история, през която той преминава? Използвате ли различни стратегии за разгръщане?
Ако всички отговори са 'да', значи вие сте наистина невероятни! Напишете отговорите в коментарите — ще се радвам).
Обратна връзка
Това е най-сложната практика от всички. На конференцията DevOpsConf колегата от Infobip, когато я обясняваше, леко се заплете в думите, защото наистина е много сложна работа, която изисква да се наблюдава абсолютно всичко!
Например, преди много време, когато работех в Qik и осъзнахме, че трябва да наблюдаваме всичко. Направихме това и в Zabbix се появиха 150 000 items, които се наблюдават постоянно. Беше ужасяващо, техническият директор въртеше пръст в слепоочието:
— Хей, защо се занимавате с сервера с непонятни неща?
Но след това се случи събитие, което показа, че всъщност това е страхотна стратегия.
Постоянно започна да пада един от сервисите. Първоначално той не падаше, което е интересно, не се добавяше код там, защото беше базов брокер, в който почти нямаше бизнес функционалност – той просто прехвърляше съобщения между отделни услуги. Сервисът не се променяше 4 месеца, и изведнъж започна да пада с грешка «Segmentation fault».
Бяхме в шок, отворихме графиките си в Zabbix и установихме, че всъщност 1,5 седмици по-рано поведението на заявките в API-сервиса, който използва този брокер, се е променило. След това погледнахме и видяхме, че е променена честотата на изпращане на определен тип съобщения. По-късно разкрихме, че това са android-клиентите. Попитахме:
— Хей, какво се случи с вас преди 1,5 седмици?
В отговор получихме интересна история, че са преработили потребителския интерфейс. Вероятно никой веднага няма да каже, че са сменили HTTP-библиотеката. За android-клиентите това е като да смениш сапун в банята – те просто не помнят. В крайна сметка, след 40 минути разговор, установихме, че наистина са сменили HTTP-библиотеката, и тя е променилa дефолтните тайминги. Това доведе до промяна в поведението на трафика на API сървъра, което и предизвика ситуацията, довела до състезание вътре в брокера, и той започна да пада.
Без дълбок мониторинг това изобщо не би могло да бъде открито.. Ако в организацията има проблеми с "колодците", когато всеки прехвърля отговорността един на друг, това може да продължи с години. Просто рестартирате сървъра, тъй като е невъзможно да се реши проблема. Когато наблюдавате, проследявате, следите всички събития, които имате, и използвате мониторинг като тест - пишете кода и веднага посочвате как да го мониторите, също под формата на код (ние вече имаме инфраструктура като код), всичко става ясно като на длан. Дори такива сложни проблеми могат лесно да се проследят.
Събирайте всяка информация за това, какво се случва с артефакта на всяка стъпка от процеса на доставка - не в продукция.
Мониторингът заредете на CI, и там вече ще бъдат видими основни неща. След това ще ги видите и в Test, и в PredProd, и в теста на натоварване. Събирайте информация на всички етапи, не само метрики, статистика, но и логове: как е излязло приложението, аномалии - събирайте всичко.
В противен случай ще бъде трудно да се разбере. Вече казах, че DevOps е по-голяма сложност. За да се справите с тази сложност, трябва да имате нормална аналитика..
Въпроси за самоосноваване
Вашият мониторинг и регистриране – инструмент за разработка ли са за вас? Вашите разработчици, включително и вие, когато пишете код, мислите ли как да го мониторите?
Разбирате ли за проблемите от клиенти? Разбирате ли клиента по-добре чрез мониторинг и регистриране? Разбирате ли системата по-добре чрез мониторинг и регистриране? Променяте ли системата просто защото виждате, че трендът в системата расте и осъзнавате, че след 3 седмици всичко ще се провали?
Когато имате тези три компонента, можете да помислите каква инфраструктурна платформа имате във вашата компания.
Инфраструктурна платформа
Смисълът не е в това, че това е набор от разпокъсани инструменти, които съществуват в всяка компания.
Смисълът на инфраструктурната платформа е в това, че всички екипи използват тези инструменти и ги развиват съвместно.
Разбира се, че има отделни екипи, които носят отговорност за развитието на отделни части от инфраструктурната платформа. Но същевременно отговорността за развитието, функционирането и промотирането на инфраструктурната платформа носи всеки инженер. На вътрешно ниво това става общ инструмент.
Всички екипи развиват инфраструктурната платформа, отнасят се към нея като към собственото си IDE. В своето IDE вие добавяте различни плъгини, за да е всичко красиво и бързо, настройвате горещи клавиши. Когато отворите Sublime, Atom или Visual Studio Code, виждате как кодът изобилства от грешки и разбирате, че е почти невъзможно да работите, веднага се тъгувате и бързате да поправите своето IDE.
Също така се отнасяйте към вашата инфраструктурна платформа. Ако разбирате, че нещо не е наред, оставяйте заявка, ако не можете да поправите сами. Ако обаче проблемът е прост – поправете самостоятелно, изпратете pull request – момчетата ще го разгледат и добавят. Това е малко по-различен подход към инженерния инструментариум в главата на разработчика.
Инфраструктурната платформа осигурява пренос на артефакта от разработката до клиента с постоянно повишаване на качеството. В ИП е програмиран набор от истории, които се случват с кода в продукция. През годините на разработка тези истории се увеличават, част от тях са уникални и се отнасят само до вас – не могат да се намерят в интернет.
В този момент инфраструктурната платформа става вашето конкурентно предимство, защото в нея е вложено това, което липсва в инструмента на конкурента. Колкото по-дълбока е вашата ИП, толкова по-голямо е вашето конкурентно предимство в смисъл на Time-to-market. Тук се появява проблемът с vendor lock: можете да вземете чужда платформа, но използвайки чуждия опит, няма да разберете колко е релевантен за вас. Да, не всяка компания може да изгради платформа като Amazon. Това е тънка граница, където опитът на компанията е релевантен на позицията ѝ на пазара, и не бива да се допуска vendor lock. Това е важен аспект, върху който също трябва да се помисли.
Схема
Това е основната схема на инфраструктурната платформа, която ще ви помогне да установите всички практики и процеси в DevOps компанията.
Нека разгледаме от какво се състои.
Система за оркестрация на ресурси, която предоставя CPU, памет, диск на приложенията и другите услуги. Над това – услугите с ниско ниво: мониторинг, логване, CI/CD Engine, хранилище на артефакти, инфраструктура като код системи.
Услугите с по-високо ниво: база данни като услуга, опашки като услуга, Load Balance като услуга, resizing на изображения като услуга, Big Data фабрика като услуга. На върха на това — пайплайн, който предоставя постоянно модифициран код на клиента ви.
Вие получавате информация за това как вашият софтуер работи при клиента, променяте, отново предоставяте този код, получавате информация — и така постоянно развивате и инфраструктурната платформа, и вашия софтуер.
На схемата delivery pipeline се състои от множество стъпки. Но това е принципна схема, предоставена за пример — не е нужно да я повтаряте точно еднакво. Стъпките взаимодействат с услугите, както с услуги — всеки елемент на платформата носи своя история: как се разпределят ресурсите, как приложението се стартира, работи с ресурсите, мониторира се, променя се.
Важно е да разберете, че всяка част от платформата носи история и да се питате — каква история носи този елемент, може би си заслужава да бъде заменен с външна услуга. Например, може ли вместо елемент да поставим Okmeter? Вероятно, момчетата вече са развили тази експертиза много повече от нас. Но може и да не е така — възможно е да имаме уникална експертиза, трябва да поставим Prometheus и да развиваме това по-нататък.
Създаване на платформа
Това е сложен комуникационен процес. Когато имате основни практики, стартирате комуникация между различни инженери и специалисти, които разработват изисквания и стандарти и непрекъснато ги променят в зависимост от различни инструменти и подходи. Тук важна е културата, която съществува в DevOps.
С културата всичко е много просто — това е сътрудничество и комуникация, тоест желание да работите в общото поле заедно, желание да овладеете един инструмент заедно. Тук няма никаква rocket science — всичко е много просто, банално. Например, ние всички живеем в блока и поддържаме чистотата му — такова ниво на култура.
А как е при вас?
Отново въпроси, които можете да зададете на себе си.
Разграничена ли е инфраструктурната платформа? Кой отговаря за нейното развитие? Разбирате ли конкурентните предимства на вашата инфраструктурна платформа?
Тези въпроси трябва постоянно да си задавате. Ако нещо може да бъде извлечено на външни услуги — трябва да се извлече, ако външната услуга започне да блокира действията ви, трябва да изградите система вътре в себе си.
И така, DevOps...
... това е сложна система, в която трябва да има:
- Цифров продукт.
- Бизнес модули, които развиват този цифров продукт.
- Продуктови екипи, които пишат код.
- Практики за непрекъсната доставка.
- Платформи като услуга.
- Инфраструктура като услуга.
- Инфраструктура като код.
- Отделни практики за поддържане на надеждността, вградени в DevOps.
- Практика за обратна връзка, която описва всичко това.
Можете да използвате тази схема, като я оцветите в това, което вече имате в компанията си в някаква форма: това се е развило или все още трябва да се развива.
Вече след няколко седмици ще се проведе . в частта на РИТ++. Заповядайте на конференцията, където ви очакват много интересни доклади за непрекъсната доставка, инфраструктура като код и DevOps трансформация. , последен срок за цени 20 май
Източник: habr.com
