Дефиницията на DevOps е много сложна, така че трябва да започваме дискусията за нея всеки път отначало. Само на Хабре има хиляди публикации по тази тема. Но ако четете това, вероятно знаете какво е DevOps. Защото не съм. Здравей! Името ми е Александър Титов (@), и просто ще говорим за DevOps и ще споделя своя опит.
Дълго време мислех как да направя моята история полезна, така че тук ще има много въпроси - тези, които задавам на себе си, и тези, които задавам на клиентите на нашата компания. Отговаряйки на тези въпроси, разбирането става по-добро. Ще ви кажа защо е необходим DevOps от моя гледна точка, какво е, отново, от моя гледна точка и как да разберете, че отново се движите към DevOps от моя гледна точка. Последната точка ще бъде чрез въпроси. Като си отговорите сами, можете да разберете дали вашата компания се движи към DevOps или има проблеми по някакъв начин.
По едно време се носех по вълните на сливания и придобивания. Първо работих за малка стартираща компания, наречена Qik, след това беше закупена от малко по-голяма компания, наречена Skype, която след това беше закупена от малко по-голяма компания, наречена Microsoft. В този момент започнах да виждам как идеята за DevOps се трансформира в компании с различен размер. След това се заинтересувах да погледна DevOps от пазарна гледна точка и с мои колеги основахме компанията Express 42. Вече 6 години се движим по вълните на пазара.
Освен всичко друго, аз съм един от организаторите на московската общност DevOps и организатор на DevOps-Days 2017, но не съм организирал 2018. Експрес 42 работи с много компании. Ние отглеждаме DevOps там, наблюдаваме как се случва, правим заключения, анализираме, казваме на всички нашите заключения и обучаваме хората в практиките на DevOps. Като цяло, ние правим всичко възможно да увеличим нашия опит и експертиза в това отношение.
Защо DevOps
Първият въпрос, който тормози всички и винаги е – защо? Много хора смятат, че DevOps е просто автоматизация или нещо подобно, което всяка компания вече е имала.
— Имахме непрекъсната интеграция — това означава, че вече имахме DevOps и защо са необходими всички тези неща? В чужбина се забавляват, а на нас ни пречат да работим!
За 9 години развитие на общността и методологията вече стана ясно, че това все още не е маркетингов блясък, но все още не е напълно ясно защо е необходимо. Като всеки инструмент и процес, DevOps има конкретни цели, които в крайна сметка постига.
Всичко това се дължи на факта, че светът се променя. Той се отдалечава от корпоративния подход, когато компаниите се движат право към една мечта, както пее нашият петербургски класик, от точка А до точка Б според определена стратегия, с определена структура, изградена за това.
По принцип всичко в ИТ трябва да се изгражда според този подход. Тук ИТ се използва изключително за автоматизиране на процеси.
Автоматизацията не се променя често, защото когато една компания тръгне по добре утъпкания коловоз, какво има да се променя? Работи - не го пипайте. Сега подходите в света се променят и този, наречен Agile, предполага, че крайна точка B не се вижда веднага.
Когато една компания минава през пазара, работи с клиент, тя непрекъснато проучва пазара и променя крайната точка B. Освен това, колкото по-често компанията променя посоката си, толкова по-успешна е в крайна сметка, защото избира повече пазар ниши.
Стратегията е демонстрирана от една интересна компания, за която научих наскоро. One Box Shave е абонаментна услуга за доставка на самобръсначки и принадлежности за бръснене в кутия. Те знаят как да персонализират своята „кутия“ за различни клиенти. Това се прави от определен софтуер, който след това изпраща поръчката до корейската фабрика, която произвежда стоките.
Този продукт беше закупен от Unilever за 1 милиард долара. Сега се конкурира с Gillette и е отнел значителен дял от потребителите на американския пазар. One Box Shave казва:
— 4 остриета? Сериозен ли си? Защо ви трябва това - не подобрява качеството на бръснене. Специално подбран крем, аромат и висококачествена самобръсначка с две ножчета решават много повече проблеми от онези глупави 4 ножчета Gillette! Ще стигнем ли скоро до 10?
Ето как се променя светът. Unilever твърдят, че имат страхотна ИТ система, която ви позволява да направите това. В крайна сметка изглежда като концепция Време за пускане на пазара, за които вече никой не е говорил.
Смисълът на Time-to-market не е колко често внедряваме. Често можете да внедрявате, но циклите на пускане ще бъдат дълги. Ако тримесечните цикли на освобождаване се наслагват един върху друг, измествайки ги с една седмица, се оказва, че компанията изглежда внедрява веднъж седмично. А от идеята до окончателното изпълнение минават 3 месеца.
Времето за пускане на пазара означава минимизиране на времето от идеята до окончателното изпълнение.
В този случай софтуерът взаимодейства с пазара. Ето как уебсайтът One Box Shave взаимодейства с клиента. Те нямат търговци - просто уебсайт, където посетителите кликват и оставят желания. Съответно нещо ново трябва постоянно да се публикува на сайта и да се актуализира в съответствие с желанията. Например в Южна Корея се бръснат по различен начин, отколкото в Русия, и харесват аромата не на бор, а например на моркови и ванилия.
Тъй като е необходимо бързо да се промени съдържанието на сайта, разработката на софтуер се променя значително. Чрез софтуера трябва да разберем какво иска клиентът. Преди това научихме това по заобиколни начини, например чрез бизнес управление. След това го проектирахме, поставихме изискванията в ИТ системата и всичко беше готино. Сега е различно – софтуерът се проектира от всички, които участват в процеса, включително инженерите, защото чрез технически спецификации те научават как работи пазарът и също така споделят своите прозрения с бизнеса.
Например в Qik внезапно научихме, че хората наистина харесват качването на списъци с контакти на сървъра и те ни предоставиха приложение. Първоначално не мислехме за това. В една класическа компания всеки би решил, че това е бъг, тъй като спецификацията не казваше, че трябва да работи страхотно и като цяло беше внедрена на коляното, те щяха да изключат функцията и да кажат: „Никой не се нуждае от това, най-важното е основната функционалност да работи.” . И технологичната компания вижда това като възможност и започва да променя софтуера в съответствие с това.
През 1968 г. визионер, Мелвин Конуей, формулира следната идея.
Организацията, която създава системата, е ограничена от дизайн, който възпроизвежда комуникационната структура на тази организация.
По-подробно, за да произвеждате системи от различен тип, трябва да имате и комуникационна структура в компания от различен тип. Ако комуникационната ви структура е най-йерархична, тогава това няма да ви позволи да създавате системи, които могат да осигурят много висок индикатор за време за пускане на пазара.
Прочети може да . Важно е за разбирането на културата или философията на DevOps, защото единственото нещо, което фундаментално се променя в DevOps, е структурата на комуникация между екипите.
От гледна точка на процеса, преди DevOps, всички етапи: анализ, разработка, тестване, експлоатация, бяха линейни.
В случая на DevOps всички тези процеси се случват едновременно.
Времето за пускане на пазара е единственият начин, по който това може да стане. За хората, които са работили по стария процес, това изглежда някак космическо и като цяло така.
Така че защо имате нужда от DevOps?
За разработване на дигитални продукти. Ако вашата компания няма дигитален продукт, DevOps не е необходим – той е много важен.
DevOps преодолява ограниченията на скоростта на последователното производство на софтуер. В него всички процеси протичат едновременно.
Трудността се увеличава. Когато евангелистите на DevOps ви казват, че ще ви улесни да пускате софтуер, това са глупости.
С DevOps нещата само ще се усложнят.
На конференцията на щанда на Avito можете да видите какво е внедряването на Docker контейнер – нереалистична задача. Сложността става непосилна; трябва да жонглираш с много топки едновременно.
DevOps напълно променя процеса и организацията в компанията — по-точно, не се променя DevOps, а цифровият продукт. За да стигнете до DevOps, все още трябва напълно да промените този процес.
Въпроси към специалист
Какво имаш? Въпроси, които можете да си зададете докато работите във фирма и се развивате като специалист.
Имате ли стратегия за създаване на дигитален продукт? Ако има, това вече е добре. Това означава, че вашата компания се движи към DevOps.
Вашата компания създава ли вече дигитален продукт? Това означава, че можете да се издигнете още едно ниво по-високо и да правите нещата по-интересно – отново от гледна точка на DevOps. Говоря само от тази гледна точка.
Вашата компания един от пазарните лидери в дигиталната продуктова ниша ли е? Spotify, Yandex, Uber са компании, които сега са на върха на технологичния прогрес.
Задайте си тези въпроси и ако всички отговори са отрицателни, тогава може би не трябва да правите DevOps в тази компания. Ако темата за DevOps наистина ви е интересна, може би... трябва да се преместите в друга компания? Ако вашата компания иска да влезе в DevOps, но сте отговорили с „Не“ на всички въпроси, тогава тя е като красивия носорог, който никога няма да се промени.
Организация
Както казах, според закона на Конуей организацията на една компания се променя. Ще започна с това какво пречи на DevOps да проникне вътре в компанията от организационна гледна точка.
Проблемът с "кладенците"
Английската дума "Silo" тук се превежда на руски като "кладенец". Смисълът на този проблем е, че няма обмен на информация между екипите. Всеки екип се задълбочава в своя опит, без да изгражда обща карта за навигация.
В известен смисъл това ми напомня за човек, който току-що е пристигнал в Москва и все още не знае как да се ориентира в картата на метрото. Московчаните обикновено познават района си много добре и в Москва могат да се ориентират с помощта на картата на метрото. Когато дойдеш в Москва за първи път, нямаш това умение и просто си дезориентиран.
DevOps предлага да преминете през този момент на дезориентация и всички отдели да работят заедно, за да изградят обща карта на взаимодействие.
Два фактора пречат на това.
Последица от системата за корпоративно управление. Изгражда се в отделни йерархични „кладенци“. Например, има определени KPI в компании, които поддържат тази система. От друга страна, мозъците на човек, който се затруднява да надхвърли границите на своята експертиза и да се ориентира в цялата система, пречи. Просто е неудобно. Представете си, че сте на летището в Банкок - няма да се ориентирате бързо. DevOps също е труден за навигация и затова хората казват, че трябва да намерите ръководство, за да стигнете до там.
Но най-важното е, че проблемът с „кладенците“ за инженер, който е пропит от духа на DevOps, чел е Фаулър и куп други книги, се изразява във факта, че "кладенци" не ви позволяват да правите "очевидни" неща. Често се събираме след DevOps Москва, говорим си и хората се оплакват:
— Просто искахме да стартираме CI, но се оказа, че ръководството не се нуждае от него.
Това се случва именно защото CI и Непрекъснат процес на доставка са на границата на много прегледи. Просто без да преодолеете проблема с „кладенците“ на организационно ниво, няма да можете да продължите напред, каквото и да правите и колкото и да е тъжно.
Всеки участник в процеса във фирмата: backend и frontend разработчици, тестване, DBA, операция, мрежа, копае в собствената си посока и никой няма обща карта освен мениджъра, който по някакъв начин ги следи и управлява с помощта на „divide и завладей”.
Хората се борят за някакви звезди или знамена, всеки си рови експертизата.
В резултат на това, когато възникне задачата да свържем всичко това заедно и да изградим общ тръбопровод и вече няма нужда да се борим за звезди и знамена, възниква въпросът - какво да правим? Трябва да се споразумеем някак, но никой не ни е учил как се прави това в училище. От училище ни учат: осми клас - леле! - спрямо седми клас! Тук е същото.
Така ли е във вашата компания?
За да проверите това, можете да си зададете следните въпроси.
Екипите използват ли общи инструменти и допринасят ли за промени в тези общи инструменти?
Колко често екипите се реорганизират – някои специалисти от един екип преминават в друг? В среда на DevOps това става нормално, защото понякога човек просто не може да разбере какво прави друга област на експертиза. Той се премества в друг отдел, работи там две седмици, за да създаде за себе си карта на ориентация и взаимодействие с този отдел.
Възможно ли е да се сформира комисия за промяна и да се променят нещата? Или изисква силната ръка на най-висшето ръководство и ръководство? Наскоро писах във Facebook как една малко известна банка внедрява инструменти чрез поръчки: пишем поръчка, прилагаме я за една година и вижте какво ще се случи. Това, разбира се, е дълго и тъжно.
Колко важно е мениджърите да получават лични постижения, без да вземат предвид постиженията на компанията?
Ако сами си отговорите на тези въпроси, ще стане по-ясно дали имате такъв проблем във вашата компания.
Инфраструктурата като код
След като този проблем бъде преминат, първата важна практика, без която е трудно да се напредне по-нататък в DevOps, е инфраструктура като код.
Най-често инфраструктурата като код се възприема по следния начин:
— Нека автоматизираме всичко в bash, да се покрием със скриптове, така че администраторите да имат по-малко ръчна работа!
Но това не е вярно.
Инфраструктурата като код означава, че описвате ИТ системата, с която работите, под формата на код, за да разбирате постоянно нейното състояние.
Заедно с други екипи създавате карта под формата на код, който всеки може да разбере и може да навигира и навигира. Няма значение на какво се прави – Chef, Ansible, Salt или използване на YAML файлове в Kubernetes – няма разлика.
На конференцията колега от 2GIS разказа как са направили собствено вътрешно нещо за Kubernetes, което описва структурата на отделните системи. За да опишат 500 системи, те се нуждаеха от отделен инструмент, който генерира това описание. Когато има това описание, всеки може да проверява помежду си, да следи промените, как да го промени и подобри, какво липсва.
Съгласете се, отделните bash скриптове обикновено не предоставят това разбиране. В една от компаниите, в които работех, дори имаше име за скрипт само за писане - когато скриптът е написан, но вече не може да се прочете. Мисля, че това също ви е познато.
Инфраструктурата като код код, който описва текущото състояние на инфраструктурата. Много екипи за продукти, инфраструктура и услуги работят заедно върху този код и най-важното е, че всички те трябва да разберат как всъщност работи този код.
Кодът се поддържа в съответствие с най-добрите практики за кодиране: съвместна разработка, преглед на код, XP-програмиране, тестване, заявки за изтегляне, CI за кодови инфраструктури - всичко това е подходящо и може да се използва.
Кодът става общ език за всички инженери.
Промяната на инфраструктурата в кода не отнема много време. Да, инфраструктурният код може да има и технически дълг. Обикновено екипите се сблъскват с него година и половина, след като са започнали да внедряват „инфраструктура като код“ под формата на куп скриптове или дори Ansible, които пишат като спагети код, и също така добавят bash скриптове в сместа!
Важно е: Ако все още не сте опитвали тези неща, запомнете го Ansible не е bash! Прочетете внимателно документацията, проучете какво пишат за нея.
Инфраструктурата като код е разделянето на инфраструктурния код на отделни слоеве.
В нашата компания разграничаваме 3 основни слоя, които са много ясни и прости, но може да има повече от тях. Можете да погледнете вашия инфраструктурен код и да кажете дали имате това условие или не. Ако не са маркирани слоеве, тогава трябва да отделите малко време и да преработите малко.
основен пласт - така се конфигурират ОС, резервни копия и други неща на ниско ниво, например как се внедрява Kubernetes на основно ниво.
Ниво на обслужване - това са услугите, които предоставяте на разработчика: регистриране като услуга, наблюдение като услуга, база данни като услуга, балансьор като услуга, опашка като услуга, непрекъсната доставка като услуга - куп услуги, които отделните екипи може да предостави на развитието. Всичко това трябва да бъде описано в отделни модули във вашата система за управление на конфигурацията.
Слоят, където се правят приложенията и описва как те ще се разгънат върху предишните два слоя.
Контролни въпроси
Вашата компания има ли общо хранилище на инфраструктурата? Управлявате ли технически дълг във вашата инфраструктура? Използвате ли практики за разработка в инфраструктурно хранилище? Вашата инфраструктура нарязана ли е на слоеве? Можете да проверите диаграмата Base-service-APP. Колко трудно е да се направи промяна?
Ако сте преживели, че е отнел ден и половина, за да направите промени, това означава, че имате технически дълг и трябва да работите с него. Току-що се натъкнахте на технически рейк на дълга във вашия инфраструктурен код. Спомням си много такива истории, когато, за да промените някои CCTL, трябва да пренапишете половината от инфраструктурния код, защото креативността и желанието да се автоматизира всичко доведе до факта, че всичко е корозирало навсякъде, всички дръжки са премахнати и необходимо е да се преработи.
Непрекъсната доставка
Нека сравним дебита с кредита. Първо идва описание на инфраструктурата, която може да бъде доста елементарна. Не е нужно да описвате всичко подробно, но е необходимо някакво основно описание, за да можете да работите с него. В противен случай не е ясно какво да правим с непрекъснатата доставка по-нататък. Всички тези практики се разгръщат едновременно, когато стигнете до DevOps, но започва с разбирането какво имате и как да го управлявате. Това е именно практиката на инфраструктурата като код.
След като стане ясно, че го имате и как да го управлявате, започвате да измисляте как да изпратите кода на разработчиците до производството възможно най-бързо. Имам предвид заедно с разработчика - помним за проблема с „кладенците“, тоест не отделни хора идват с това, а екип.
Когато сме с Ваня Евтухович видях първата книга Джез Хъмбъл и авторски групи "Непрекъсната доставка", който излезе през 2009 г., дълго мислихме как да преведем заглавието му на руски. Искаха да го преведат като „Постоянно доставяне“, но за съжаление беше преведено като „Непрекъснато доставяне“. Струва ми се, че има нещо руско в името ни, с натиск.
Постоянно доставящи средства
Кодът, който е в продуктовото хранилище, винаги може да бъде изтеглен в производството. Може да не е обезсърчен, но винаги е готов за това. Съответно, винаги пишете код с трудно обяснимо чувство на някакво безпокойство под опашната кост. Често се появява, когато внедрявате инфраструктурен код. Това чувство на известно безпокойство трябва да присъства - то задейства мозъчни процеси, които ви позволяват да пишете код малко по-различно. Това трябва да бъде записано в правилата в рамките на разработката.
За да доставяте последователно, имате нужда от формат на артефакт, който работи през инфраструктурна платформа. Ако хвърлите „жизнени отпадъци“ от различни формати в инфраструктурна платформа, тогава тя става унифицирана, поддържа се трудно и възниква проблемът с техническия дълг. Форматът на артефакта трябва да бъде съгласуван - това също е колективна задача: всички трябва да се съберем, да си размърдаем мозъка и да измислим този формат.
Артефактът непрекъснато се подобрява и се променя, за да отговаря на производствената среда, докато се движи през тръбопровода за доставка. Когато артефактът се движи по тръбопровода, той непрекъснато се натъква на някои неудобни неща за него, които са подобни на това, което среща артефактът, който поставяте в производство. Ако в класическата разработка това се прави от системен администратор, който прави внедряването, тогава в процеса на DevOps това се случва през цялото време: тук го тестваха с някои тестове, тук го хвърлиха в Kubernetes клъстер, който е повече или по-малко подобен до производство, след това внезапно започнаха тестове за натоварване.
Това донякъде напомня на играта Pac-Man - артефактът преминава през някаква история. В същото време е важно да контролирате дали кодът действително преминава през историята и дали е свързан по някакъв начин с вашата продукция. Историите от производството могат да бъдат влачени в процеса на непрекъсната доставка: беше така, когато нещо падна, сега нека просто програмираме този сценарий вътре в системата. Всеки път кодът също ще преминава през този сценарий и следващия път няма да срещнете този проблем. Ще научите за това много по-рано, отколкото ще стигне до вашия клиент.
Различни стратегии за внедряване. Например, вие използвате AB тестване или разгръщане на canary, за да тествате кода по различен начин на различни клиенти, да получите информация за това как работи кодът и много по-рано, отколкото когато бъде пуснат на 100 милиона потребители.
„Постоянно доставяне“ изглежда така.
Процесът на доставка Dev, CI, Test, PreProd, Prod не е отделна среда, това са етапи или станции с огнеупорни суми, през които преминава вашият артефакт.
Ако имате инфраструктурен код, който е описан като Base Service APP, тогава това помага не забравяйте всички скриптовеи ги запишете като код за този артефакт, насърчаване на артефакт и го променяйте, докато вървите.
Въпроси за самодиагностика
Времето от описанието на функцията до пускането в производство в 95% от случаите е по-малко от седмица? Качеството на артефакта подобрява ли се на всеки етап от тръбопровода? Има ли история, през която минава? Използвате ли различни стратегии за внедряване?
Ако всички отговори са да, значи сте невероятно готини! Напишете отговорите си в коментарите - ще се радвам).
Обратна връзка
Това е най-трудната практика от всички. На конференцията DevOpsConf колега от Infobip, говорейки за това, беше малко объркан в думите си, защото това наистина е много сложна практика за това, че трябва да следите всичко!
Например, преди много време, когато работех в Qik и разбрахме, че трябва да следим всичко. Направихме това и сега имаме 150 000 елемента в Zabbix, които се наблюдават постоянно. Беше страшно, техническият директор изви пръст на слепоочието си:
- Момчета, защо изнасилвате сървъра с нещо неясно?
Но тогава се случи инцидент, който показа, че това наистина е много яка стратегия.
Една от услугите започна да забива постоянно. Първоначално не се срина, което е интересно, кодът не беше добавен там, защото беше основен брокер, който практически нямаше бизнес функционалност - просто изпращаше съобщения между отделните услуги. Услугата не се промени в продължение на 4 месеца и изведнъж започна да се срива с грешката „Segmentation fault“.
Бяхме шокирани, отворихме графиките си в Zabbix и се оказа, че преди седмица и половина поведението на заявките в API услугата, която този брокер използва, се промени значително. След това видяхме, че честотата на изпращане на определен тип съобщения се е променила. По-късно разбрахме, че това са андроид клиенти. Ние попитахме:
– Момчета, какво ви се случи преди седмица и половина?
В отговор чухме интересна история за това как са преработили потребителския интерфейс. Малко вероятно е някой веднага да каже, че е променил HTTP библиотеката. За клиентите с Android това е като смяна на сапун в банята - те просто не помнят. В резултат на това след 40 минути разговор разбрахме, че са променили HTTP библиотеката и нейните времена по подразбиране са се променили. Това доведе до промяна на поведението на трафика на API сървъра, което доведе до ситуация, която предизвика надпревара в брокера и той започна да се срива.
Без задълбочен мониторинг обикновено е невъзможно да се отвори това. Ако организацията все още има проблема с „кладенците“, когато всички хвърлят пари един на друг, това може да продължи с години. Просто рестартирате сървъра, защото е невъзможно да се реши проблема. Когато наблюдавате, проследявате, проследявате всички събития, които имате, и използвате мониторинга като тестване - напишете код и веднага посочете как да го наблюдавате, също под формата на код (вече имаме инфраструктурата като код), всичко става ясно как на дланта. Дори такива сложни проблеми се проследяват лесно.
Съберете цялата информация за това какво се случва с артефакта на всеки етап от процеса на доставка - не в производството.
Качете мониторинга в CI и някои основни неща вече ще се виждат там. По-късно ще ги видите в Test, PredProd и тестване при натоварване. Събирайте информация на всички етапи, не само показатели, статистики, но и регистрационни файлове: как е пуснато приложението, аномалии - събирайте всичко.
В противен случай ще бъде трудно да го разберете. Вече казах, че DevOps е по-сложен. За да се справите с тази сложност, трябва да имате нормален анализ.
Въпроси за самоконтрол
Вашето наблюдение и регистриране инструментът за разработка ли е за вас? Когато пишете код, вашите разработчици, включително и вие, мислят ли как да го наблюдават?
Чувате ли за проблеми от клиенти? Разбирате ли клиента по-добре от наблюдението и регистрирането? Разбирате ли системата по-добре от наблюдение и регистриране? Сменяте ли системата просто защото сте видели, че тенденцията в системата расте и разбирате, че след още 3 седмици всичко ще умре?
След като имате тези три компонента, можете да помислите какъв вид инфраструктурна платформа имате във вашата компания.
Инфраструктурна платформа
Въпросът не е, че това е набор от различни инструменти, които всяка компания има.
Смисълът на инфраструктурната платформа е всички екипи да използват тези инструменти и да ги развиват заедно.
Ясно е, че има отделни екипи, които отговарят за развитието на отделни части от инфраструктурната платформа. Но в същото време всеки инженер носи отговорност за развитието, работата и популяризирането на инфраструктурната платформа. На вътрешно ниво това се превръща в общ инструмент.
Всички екипи разработват инфраструктурната платформа и я третират внимателно като своя собствена IDE. Във вашето IDE инсталирате различни добавки, за да направите всичко хубаво и бързо, и конфигурирате клавишни комбинации. Когато отворите Sublime, Atom или Visual Studio Code, грешките в кода се изсипват и осъзнавате, че изобщо е невъзможно да работите, веднага се чувствате тъжни и тичате да поправите вашата IDE.
Отнасяйте се към вашата инфраструктурна платформа по същия начин. Ако разберете, че има нещо нередно с него, оставете заявка, ако не можете да го поправите сами. Ако има нещо просто, редактирайте го сами, изпратете заявка за изтегляне, момчетата ще го разгледат и ще го добавят. Това е малко по-различен подход към инженерните инструменти в главата на разработчика.
Инфраструктурната платформа осигурява прехвърлянето на артефакта от разработка към клиента с непрекъснато подобряване на качеството. IP е програмиран с набор от истории, които се случват с кода в производството. През годините на развитие има много от тези истории, някои от тях са уникални и се отнасят само за вас - те не могат да бъдат Googled.
В този момент инфраструктурната платформа става вашето конкурентно предимство, защото има нещо вградено в него, което не е в инструмента на конкурента. Колкото по-дълбоко е вашето IP, толкова по-голямо е вашето конкурентно предимство по отношение на времето за излизане на пазара. Появява се тук проблем със заключването на доставчика: Можете да вземете платформата на някой друг, но използвайки опита на някой друг, няма да разберете колко е подходяща за вас. Да, не всяка компания може да изгради платформа като Amazon. Това е трудна линия, където опитът на компанията е от значение за нейната позиция на пазара и не можете да използвате заключване на доставчик там. Това също е важно да се помисли.
Схемата
Това е основна диаграма на инфраструктурна платформа, която ще ви помогне да настроите всички практики и процеси в DevOps компания.
Нека да разгледаме от какво се състои.
Система за оркестрация на ресурсите, който предоставя процесор, памет, диск за приложения и други услуги. На всичкото отгоре - услуги на ниско ниво: наблюдение, регистриране, CI/CD Engine, съхранение на артефакти, инфраструктура като системен код.
Услуги от по-високо ниво: база данни като услуга, опашки като услуга, балансиране на натоварването като услуга, преоразмеряване на изображения като услуга, фабрика за големи данни като услуга. На всичкото отгоре - тръбопровод, който доставя постоянно модифициран код на вашия клиент.
Получавате информация за това как вашият софтуер работи за клиента, променяте го, предоставяте отново този код, получавате информация - и така непрекъснато развивате както инфраструктурната платформа, така и вашия софтуер.
На диаграмата тръбопроводът за доставка се състои от много етапи. Но това е схематична диаграма, която е дадена като пример - няма нужда да я повтаряме една по една. Етапите взаимодействат с услугите, сякаш са услуги – всяка тухла на платформата носи своя собствена история: как се разпределят ресурсите, как се стартира приложението, работи с ресурси, наблюдава се и се променя.
Важно е да разберете, че всяка част от платформата носи история и се запитайте каква история носи тази тухла, може би трябва да бъде изхвърлена и заменена с услуга на трета страна. Например, възможно ли е да инсталирате Okmeter вместо тухла? Може би момчетата вече са развили тази експертиза много повече от нас. Но може би не - може би имаме уникален опит, трябва да инсталираме Prometheus и да го доразвием.
Създаване на платформата
Това е сложен комуникационен процес. Когато имате базови практики, започвате комуникация между различни инженери и специалисти, които разработват изисквания и стандарти и постоянно ги променят към различни инструменти и подходи. Културата, която имаме в DevOps, е важна тук.
С културата всичко е много просто - става въпрос за сътрудничество и комуникация, тоест желанието да работят в обща област един с друг, желанието да боравят с един инструмент заедно. Тук няма ракетна наука - всичко е много просто, банално. Например, ние всички живеем във входа и го поддържаме чист - такова ниво на култура.
Какво имаш?
Отново въпроси, които можете да си зададете.
Специализирана ли е инфраструктурната платформа? Кой е отговорен за развитието му? Разбирате ли конкурентните предимства на вашата инфраструктурна платформа?
Трябва постоянно да си задавате тези въпроси. Ако нещо може да бъде прехвърлено към услуги на трети страни, то трябва да бъде прехвърлено; ако услуга на трета страна започне да блокира движението ви, тогава трябва да изградите система в себе си.
И така, DevOps...
... това е сложна система, тя трябва да има:
- Дигитален продукт.
- Бизнес модули, които разработват този дигитален продукт.
- Продуктови екипи, които пишат код.
- Практики за непрекъсната доставка.
- Платформите като услуга.
- Инфраструктурата като услуга.
- Инфраструктурата като код.
- Отделни практики за поддържане на надеждност, вградени в DevOps.
- Практика за обратна връзка, която описва всичко.
Можете да използвате тази диаграма, като подчертаете в нея какво вече имате във вашата компания под някаква форма: разработено ли е или все още трябва да бъде разработено.
Ще свърши след няколко седмици . като част от RIT++. Елате на конференцията, където ще намерите много готини доклади за непрекъсната доставка, инфраструктура като код и DevOps трансформация. , крайният срок на цената е 20 май
Източник: www.habr.com