{"id":33725,"date":"2019-10-31T21:54:21","date_gmt":"2019-10-31T18:54:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-takoe-devops\/"},"modified":"2019-10-31T21:54:21","modified_gmt":"2019-10-31T18:54:21","slug":"chto-takoe-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/chto-takoe-devops","title":{"rendered":"Czym jest DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Definicja DevOps jest bardzo skomplikowana, dlatego za ka\u017cdym razem trzeba na nowo rozpoczyna\u0107 dyskusj\u0119 na ten temat. Tylko na Habrze jest tysi\u0105ce publikacji na ten temat. Ale je\u015bli to czytasz, to z pewno\u015bci\u0105 wiesz, czym jest DevOps. Bo ja sam nie wiem. Cze\u015b\u0107, nazywam si\u0119 Aleksandr Titow (@osminog<\/a><\/noindex><\/b>), i po prostu porozmawiamy o DevOps, a ja podziel\u0119 si\u0119 swoim do\u015bwiadczeniem.<\/p>\n

\"Czym
\n
\nD\u0142ugo my\u015bla\u0142em, jak uczyni\u0107 moj\u0105 opowie\u015b\u0107 u\u017cyteczn\u0105, dlatego znajdzie si\u0119 tu wiele pyta\u0144 - tych, kt\u00f3re sam sobie zadaj\u0119, oraz tych, kt\u00f3re zadaj\u0119 klientom naszej firmy. Odpowiadaj\u0105c na te pytania, rozumienie staje si\u0119 lepsze. Opowiem, po co potrzebny jest DevOps z mojego punktu widzenia, co to jest, zn\u00f3w z mojej perspektywy, oraz jak zrozumie\u0107, \u017ce zmierzasz w kierunku DevOps znowu z mojego punktu widzenia. Ostatni punkt b\u0119dzie poprzez pytania. Odpowiadaj\u0105c na nie samemu sobie, b\u0119dziecie w stanie zrozumie\u0107, czy wasza firma zmierza w kierunku DevOps, czy s\u0105 jakie\u015b problemy.
\n<\/a><\/noindex>
\n

\r\n \"Odtwarzaj\r\n
<\/div>\r\n <\/div><\/center>
\nKiedy\u015b przemieszcza\u0142em si\u0119 w falach fuzji i przej\u0119\u0107. Najpierw pracowa\u0142em w ma\u0142ym startupie Qik, kt\u00f3ry p\u00f3\u017aniej zosta\u0142 zakupiony przez troch\u0119 wi\u0119ksz\u0105 firm\u0119 Skype, a ta zosta\u0142a potem przej\u0119ta przez jeszcze wi\u0119ksz\u0105 firm\u0119 Microsoft. W tym momencie zyska\u0142em wizj\u0119, jak postrzeganie DevOps transformuje si\u0119 w r\u00f3\u017cnych wielko\u015bciach firm. Po tym zaciekawi\u0142o mnie, jak rynek postrzega DevOps, wi\u0119c z kolegami zorganizowali\u015bmy firm\u0119 Ekspress 42. Ju\u017c od 6 lat p\u0142yniemy na tym rynku.<\/p>\n

Opr\u00f3cz tego jestem jednym z organizator\u00f3w spo\u0142eczno\u015bci DevOps Moscow i organizatorem DevOps Days 2017, ale w 2018 roku nie organizowa\u0142em. Ekspress 42 wsp\u00f3\u0142pracuje z wieloma firmami. Rozwijamy tam DevOps, obserwujemy, jak to si\u0119 odbywa, wyci\u0105gamy wnioski, analizujemy, dzielimy si\u0119 swoimi spostrze\u017ceniami ze wszystkimi, uczymy ludzi praktyk DevOps. Og\u00f3lnie rzecz bior\u0105c, w ka\u017cdym sensie rozwijamy do\u015bwiadczenie i ekspertyz\u0119.<\/p>\n

Po co DevOps<\/h2>\n

\nPierwsze pytanie, kt\u00f3re nurtuje wszystkich zawsze - po co? Wiele os\u00f3b uwa\u017ca, \u017ce DevOps to po prostu automatyzacja lub co\u015b podobnego, co ju\u017c by\u0142o w ka\u017cdej firmie.<\/p>\n

- Mieli\u015bmy Continuous Integration - to znaczy, mieli\u015bmy ju\u017c DevOps, wi\u0119c po co to wszystko? Tam za granic\u0105 si\u0119 bawi\u0105, a nam przeszkadzaj\u0105 w pracy!<\/i><\/p>\n

Po 9 latach rozwoju spo\u0142eczno\u015bci i metodologii sta\u0142o si\u0119 jasne, \u017ce to wcale nie s\u0105 tylko marketingowe b\u0142yski, ale nadal nie do ko\u0144ca wiadomo, po co to wszystko. Jak w przypadku ka\u017cdego narz\u0119dzia i procesu, DevOps ma konkretne cele, kt\u00f3re ostatecznie realizuje.<\/p>\n

Wszystko to zwi\u0105zane jest z tym, \u017ce \u015bwiat si\u0119 zmienia. Odchodzi od podej\u015bcia enterprise, gdy firmy d\u0105\u017c\u0105 od razu do marzenia, jak \u015bpiewa\u0142 nasz klasyk z Petersburga, z punktu A do punktu B wed\u0142ug okre\u015blonej strategii, zbudowanej do tego celu odpowiedniej struktury. <\/p>\n

\"Czym
\n<\/p>\n

Tak naprawd\u0119 w IT wszystko powinno by\u0107 zbudowane pod to podej\u015bcie. Tutaj IT jest wykorzystywane wy\u0142\u0105cznie do automatyzacji proces\u00f3w.<\/p><\/blockquote>\n

\nAutomatyzacja rzadko si\u0119 zmienia, poniewa\u017c gdy firma toczy si\u0119 po utartej \u015bcie\u017cce \u2014 co tam zmienia\u0107? Dzia\u0142a \u2014 nie dotykaj. Obecnie na \u015bwiecie podej\u015bcia si\u0119 zmieniaj\u0105, i to, co nazywa si\u0119 s\u0142owem Agile, m\u00f3wi o tym, \u017ce docelowy punkt B nie jest od razu widoczny.<\/p>\n

\"Czym
\n
\nGdy firma dzia\u0142a na rynku i wsp\u00f3\u0142pracuje z klientem \u2014 nieustannie bada rynek i zmienia docelowy punkt B. Przy czym im cz\u0119\u015bciej firma zmienia kierunek, tym wi\u0119ksz\u0105 osi\u0105ga sukces, poniewa\u017c wybiera wi\u0119cej nisz rynkowych.<\/p>\n

Strategi\u0119 pokazuje interesuj\u0105ca firma, o kt\u00f3rej niedawno si\u0119 dowiedzia\u0142em. One Box Shave \u2014 to serwis dostarczaj\u0105cy maszynki do golenia i akcesoria do golenia w systemie subskrypcyjnym. Potrafi\u0105 dostosowa\u0107 swoj\u0105 \u201epude\u0142ko\u201d do r\u00f3\u017cnych klient\u00f3w. Zajmuje si\u0119 tym odpowiednie oprogramowanie, kt\u00f3re p\u00f3\u017aniej wysy\u0142a zam\u00f3wienie do korea\u0144skiej fabryki produkuj\u0105cej towar.<\/p>\n

Ten produkt zosta\u0142 zakupiony przez firm\u0119 Unilever za 1 miliard dolar\u00f3w. Teraz konkuruje z Gillette i zdoby\u0142 znaczn\u0105 cz\u0119\u015b\u0107 konsument\u00f3w na ameryka\u0144skim rynku. One Box Shave m\u00f3wi:<\/p>\n

\u2014 4 ostrza? Serio? Po co wam to \u2014 to wcale nie poprawia jako\u015bci golenia. Starannie dobrany krem, zapach i wysokiej jako\u015bci maszynka z dwoma ostrzami rozwi\u0105zuj\u0105 znacznie wi\u0119cej problem\u00f3w ni\u017c te g\u0142upie 4 ostrza Gillette! Wkr\u00f3tce dojdziemy do 10?<\/i><\/p>\n

Tak \u015bwiat si\u0119 zmienia. Unilever og\u0142asza, \u017ce maj\u0105 \u015bwietny system IT, kt\u00f3ry to umo\u017cliwia. W efekcie to wygl\u0105da jak koncepcja Time-to-market<\/b>, o kt\u00f3rej ju\u017c nie wiadomo, kto tylko nie m\u00f3wi\u0142.<\/p>\n

\"Czym
\n
\nZnaczenie Time-to-market nie polega na tym, jak cz\u0119sto wprowadzamy zmiany. Mo\u017cna wprowadza\u0107 zmiany cz\u0119sto, ale cykle wydania mog\u0105 by\u0107 d\u0142ugie. Je\u015bli na\u0142o\u017cymy na siebie trzy miesi\u0105ce cyklu wydania, przesuwaj\u0105c je o tydzie\u0144, wydaje si\u0119, \u017ce firma wprowadza zmiany co tydzie\u0144. A od pomys\u0142u do ostatecznej realizacji up\u0142ywa 3 miesi\u0105ce.<\/p>\n

Time-to-market to minimalizacja czasu od pomys\u0142u do ostatecznej realizacji.<\/p><\/blockquote>\n

\nW tym przypadku oprogramowanie wchodzi w interakcj\u0119 z rynkiem. Jak w One Box Shave strona internetowa wsp\u00f3\u0142dzia\u0142a z klientem. Nie maj\u0105 sprzedawc\u00f3w \u2014 to tylko strona, na kt\u00f3rej odwiedzaj\u0105cy klikaj\u0105 i zostawiaj\u0105 swoje \u017cyczenia. W zwi\u0105zku z tym na stronie trzeba ca\u0142y czas zamieszcza\u0107 co\u015b nowego, aktualizowa\u0107 j\u0105 zgodnie z \u017cyczeniami. Na przyk\u0142ad w Korei Po\u0142udniowej gol\u0105 si\u0119 inaczej ni\u017c w Rosji i wol\u0105, aby zapach nie by\u0142 sosnowy, a na przyk\u0142ad waniliowo-marchewkowy.<\/p>\n

Poniewa\u017c konieczna jest szybka zmiana zawarto\u015bci strony, rozw\u00f3j oprogramowania znacznie si\u0119 zmienia. Dzi\u0119ki oprogramowaniu musimy dowiedzie\u0107 si\u0119, co chce klient. Kiedy\u015b odkrywali\u015bmy to po\u015brednio, na przyk\u0142ad poprzez zarz\u0105dzanie biznesem. Nast\u0119pnie projektowali\u015bmy, definiowali\u015bmy wymagania w systemie IT, a wszystko by\u0142o w porz\u0105dku. Teraz jest inaczej \u2014 oprogramowanie projektuj\u0105 wszyscy zaanga\u017cowani w proces, w tym in\u017cynierowie, poniewa\u017c dowiaduj\u0105 si\u0119 przez dane techniczne, jak dzia\u0142a rynek, i dziel\u0105 si\u0119 swoimi spostrze\u017ceniami z biznesem.<\/p>\n

Na przyk\u0142ad w firmie Qik nagle odkryli\u015bmy, \u017ce ludziom bardzo podoba si\u0119 mo\u017cliwo\u015b\u0107 przesy\u0142ania list kontakt\u00f3w na serwer i przygotowali dla nas aplikacj\u0119. Pocz\u0105tkowo nie brali\u015bmy tego pod uwag\u0119. W klasycznej firmie wszyscy doszliby do wniosku, \u017ce to b\u0142\u0105d, poniewa\u017c w specyfikacji nie napisano, \u017ce to ma dzia\u0142a\u0107 \u015bwietnie i w og\u00f3le zosta\u0142o zrealizowane napr\u0119dce; wy\u0142\u0105czyliby funkcj\u0119 i powiedzieli: \u201eNikt tego nie potrzebuje, najwa\u017cniejsze, \u017ce podstawowa funkcjonalno\u015b\u0107 dzia\u0142a\u201d. Technologiczna firma widzi w tym mo\u017cliwo\u015b\u0107 i zaczyna dostosowywa\u0107 oprogramowanie do tego.<\/p>\n

\"Czym
\n
\nW 1968 roku przenikliwy cz\u0142owiek Melvin Conway sformu\u0142owa\u0142 nast\u0119puj\u0105c\u0105 ide\u0119.<\/p>\n

Organizacja, kt\u00f3ra tworzy system, jest ograniczona przez projekt, kt\u00f3ry kopiuje struktur\u0119 komunikacji w tej organizacji.<\/p><\/blockquote>\n

\nJe\u015bli chodzi o szczeg\u00f3\u0142y, aby wytwarza\u0107 systemy innego typu, trzeba dodatkowo posiada\u0107 wewn\u0119trzn\u0105 struktur\u0119 komunikacyjn\u0105 innego rodzaju. Je\u015bli w twojej firmie istnieje struktura komunikacyjna hierarchiczna, to nie pozwoli ci to tworzy\u0107 system\u00f3w, kt\u00f3re mog\u0105 zapewnia\u0107 bardzo wysoki wska\u017anik Time-to-market.<\/p>\n

Poczytaj o prawie Conwaya<\/a><\/noindex> mo\u017cna pod linkami<\/a><\/noindex>. Jest to wa\u017cne dla zrozumienia kultury lub filozofii DevOps, poniewa\u017c jedyn\u0105 rzecz\u0105, kt\u00f3ra zasadniczo zmienia si\u0119 w DevOps, jest w\u0142a\u015bnie struktura komunikacji mi\u0119dzy zespo\u0142ami.<\/b>.<\/p>\n

Z punktu widzenia procesu, przed DevOps wszystkie etapy: analityka, rozw\u00f3j, testowanie, eksploatacja, przebiega\u0142y liniowo.\"Czym
\nW przypadku DevOps wszystkie te procesy odbywaj\u0105 si\u0119 r\u00f3wnocze\u015bnie.<\/p>\n

\"Czym
\n
\nTime-to-market mo\u017ce by\u0107 realizowane tylko w ten spos\u00f3b. Dla os\u00f3b, kt\u00f3re pracowa\u0142y w starym procesie, wygl\u0105da to nieco kosmicznie i og\u00f3lnie jako\u015b tak sobie.<\/p>\n

To po co potrzebny jest DevOps?<\/h3>\n

\nDo rozwoju produkt\u00f3w cyfrowych.<\/b>Je\u015bli w twojej firmie nie ma produktu cyfrowego, DevOps nie jest potrzebny \u2014 to bardzo wa\u017cne.<\/p>\n

DevOps pokonuje ograniczenia pr\u0119dko\u015bci liniowego schematu produkcji oprogramowania.<\/b>W nim wszystkie procesy zachodz\u0105 r\u00f3wnocze\u015bnie.<\/p>\n

Zwi\u0119ksza si\u0119 z\u0142o\u017cono\u015b\u0107.<\/b> Kiedy ewangelizatorzy DevOps opowiadaj\u0105, \u017ce z nim \u0142atwiej b\u0119dzie wydawa\u0107 oprogramowanie \u2014 to jest bzdura.<\/p>\n

Z DevOps wszystko b\u0119dzie tylko trudniejsze.<\/p><\/blockquote>\n

\nNa konferencji na stoisku Avito mo\u017cna by\u0142o zobaczy\u0107, co to znaczy wdro\u017cy\u0107 kontener Docker \u2014 to niewykonalne zadanie. Z\u0142o\u017cono\u015b\u0107 staje si\u0119 nieprzyzwoita, trzeba \u017conglowa\u0107 wieloma pi\u0142kami jednocze\u015bnie.<\/p>\n

DevOps ca\u0142kowicie zmienia proces i organizacj\u0119 w firmie \u2014 dok\u0142adniej, to nie DevOps zmienia, lecz produkt cyfrowy. Aby przej\u015b\u0107 do DevOps, trzeba jednak ca\u0142kowicie zmieni\u0107 ten proces.<\/b>\u00a0Pytania dla specjalisty<\/p>\n

A co z tob\u0105? Pytania, kt\u00f3re mo\u017cesz sobie zada\u0107, pracuj\u0105c w firmie i rozwijaj\u0105c si\u0119 jako specjalista.<\/h3>\n

\nCzy masz strategi\u0119 tworzenia produktu cyfrowego?<\/p>\n

Je\u015bli tak \u2014 to ju\u017c dobrze. To oznacza, \u017ce twoja firma zmierza w kierunku DevOps.<\/b> Czy twoja firma ju\u017c tworzy produkt cyfrowy?<\/p>\n

To oznacza, \u017ce mo\u017cesz wspi\u0105\u0107 si\u0119 jeszcze wy\u017cej, zajmowa\u0107 si\u0119 ciekawszymi sprawami \u2014 z punktu widzenia DevOps ponownie. M\u00f3wi\u0119 tylko z tego punktu widzenia.<\/b> Czy twoja firma jest jednym z lider\u00f3w rynku w niszy z produktem cyfrowym?<\/p>\n

Czy Twoja firma jest jednym z lider\u00f3w rynku w niszy cyfrowych produkt\u00f3w?<\/b> Spotify, Yandex, Uber - to firmy, kt\u00f3re obecnie znajduj\u0105 si\u0119 na szczycie post\u0119pu technologicznego.<\/p>\n

Zadaj sobie te pytania, a je\u015bli na wszystkie odpowiedzi s\u0105 negatywne, to by\u0107 mo\u017ce nie warto zajmowa\u0107 si\u0119 DevOps w tej firmie. Je\u015bli jednak temat DevOps naprawd\u0119 Ci\u0119 interesuje, mo\u017ce warto przej\u015b\u0107 do innej firmy? Je\u015bli Twoja firma chce przej\u015b\u0107 do DevOps, ale na wszystkie pytania odpowiedzia\u0142e\u015b \"Nie\", to przypomina to pi\u0119knego nosoro\u017cca, kt\u00f3ry nigdy si\u0119 nie zmieni.<\/p>\n

\"Czym
\n<\/p>\n

Organizacja<\/h2>\n

\nJak ju\u017c m\u00f3wi\u0142em, zgodnie z prawem Conwaya w firmie zmienia si\u0119 organizacja. Zaczynaj\u0105c od tego, co utrudnia DevOps przenikni\u0119cie do wn\u0119trza firmy, patrz\u0105c z perspektywy organizacji.<\/p>\n

Problem \"silos\u00f3w\"<\/h3>\n

\nAngielskie s\u0142owo \"Silo\" przet\u0142umaczone jest tutaj na polski jako \"silos\". Istota tego problemu polega na tym, \u017ce mi\u0119dzy zespo\u0142ami nie ma wymiany informacji<\/b>. Ka\u017cdy zesp\u00f3\u0142 wykopuje swoj\u0105 ekspertyz\u0119 w g\u0142\u0105b, nie buduj\u0105c wsp\u00f3lnej mapy, na kt\u00f3rej mo\u017cna si\u0119 nawigowa\u0107.<\/p>\n

Przypomina to osob\u0119, kt\u00f3ra dopiero co przyjecha\u0142a do Warszawy i jeszcze nie umie orientowa\u0107 si\u0119 w komunikacji miejskiej. Mieszka\u0144cy zazwyczaj doskonale znaj\u0105 sw\u00f3j rejon, a w ca\u0142ej Warszawie orientuj\u0105 si\u0119 po mapie komunikacyjnej. Kiedy przyje\u017cd\u017casz do Warszawy po raz pierwszy, nie masz jeszcze tej umiej\u0119tno\u015bci i po prostu jeste\u015b zdezorientowany.<\/p>\n

DevOps oferuje przej\u015bcie przez ten moment dezorientacji i wsp\u00f3lne zbudowanie mapy interakcji dla wszystkich dzia\u0142\u00f3w.<\/p><\/blockquote>\n

\nUtrudniaj\u0105 to dwa czynniki.<\/p>\n

Konsekwencja korporacyjnego systemu zarz\u0105dzania.<\/b> Jest zbudowany na oddzielnych, hierarchicznych \"silosach\". Na przyk\u0142ad istniej\u0105 okre\u015blone KPI w firmach, kt\u00f3re wspieraj\u0105 ten system. Z drugiej strony, przeszkadza umys\u0142 cz\u0142owieka, kt\u00f3remu trudno wyj\u015b\u0107 poza granice swojej ekspertyzy i orientowa\u0107 si\u0119 w ca\u0142ym systemie. To po prostu niekomfortowe. Wyobra\u017a sobie, \u017ce jeste\u015b na lotnisku w Bangkoku - tam szybko nie da si\u0119 zorientowa\u0107. W DevOps te\u017c trudno si\u0119 orientowa\u0107, dlatego ludzie m\u00f3wi\u0105, \u017ce trzeba znale\u017a\u0107 przewodnika, aby si\u0119 tam dosta\u0107.<\/p>\n

Ale najwa\u017cniejsze jest to, \u017ce problem \"silos\u00f3w\" dla in\u017cyniera, kt\u00f3ry wczu\u0142 si\u0119 w ducha DevOps, przeczyta\u0142 ksi\u0105\u017cki Fowlersa i wiele innych, wyra\u017ca si\u0119 w tym, \u017ce \"silosy\" nie pozwalaj\u0105 robi\u0107 \"oczywistych\" rzeczy<\/b>. Cz\u0119sto spotykamy si\u0119 po DevOps Warsaw, rozmawiamy ze sob\u0105, a ludzie skar\u017c\u0105 si\u0119:<\/p>\n

\u2014 Chcieli\u015bmy po prostu uruchomi\u0107 CI, a okaza\u0142o si\u0119, \u017ce mened\u017cment tego nie potrzebuje.<\/i><\/p>\n

Dzieje si\u0119 tak w\u0142a\u015bnie dlatego, \u017ce\u00a0CI <\/b>i\u00a0proces dostarczania ci\u0105g\u0142ego<\/b> znajduj\u0105 si\u0119 na granicy wielu dziedzin wiedzy. Po prostu nie pokonuj\u0105c problemu \u00abstref cienia\u00bb na poziomie organizacyjnym, nie mo\u017cna p\u00f3j\u015b\u0107 dalej, cokolwiek by\u015bcie nie robili i jak smutno by to nie brzmia\u0142o.<\/p>\n

\"Czym
\n
\nKa\u017cdy uczestnik procesu w firmie: programi\u015bci backendu i frontendu, testerzy, DBA, operacje, sie\u0107, kopie w swoj\u0105 stron\u0119, a nikt nie ma wsp\u00f3lnej mapy, poza mened\u017cerem, kt\u00f3ry jako\u015b ich przegl\u0105da i zarz\u0105dza metod\u0105 \u00abdziel i rz\u0105d\u017a\u00bb.<\/p>\n

Ludzie walcz\u0105 o jakie\u015b gwiazdki lub flagi, ka\u017cdy kopie swoj\u0105 ekspertyz\u0119.<\/p><\/blockquote>\n

\nW rezultacie, gdy pojawia si\u0119 zadanie po\u0142\u0105czenia tego wszystkiego razem i ju\u017c nie trzeba walczy\u0107 o gwiazdki i flagi, pojawia si\u0119 pytanie \u2014 co w og\u00f3le robi\u0107? Jako\u015b trzeba si\u0119 dogada\u0107, a jak to zrobi\u0107, nikt nas w szkole tego nie uczy\u0142. Jeszcze ze szko\u0142y nauczyli\u015bmy si\u0119: \u00f3sma klasa \u2014 wow! \u2014 w por\u00f3wnaniu do si\u00f3dmej klasy! Tutaj jest to samo.<\/p>\n

Czy w waszej firmie jest podobnie?<\/h3>\n

\nAby to sprawdzi\u0107, mo\u017cna zada\u0107 sobie nast\u0119puj\u0105ce pytania.<\/p>\n

Czy zespo\u0142y korzystaj\u0105 z takich samych narz\u0119dzi, czy wk\u0142adaj\u0105 wk\u0142ad w zmiany tych wsp\u00f3lnych narz\u0119dzi?<\/p>\n

Jak cz\u0119sto zespo\u0142y s\u0105 reorganizowane \u2013 cz\u0119\u015b\u0107 specjalist\u00f3w z jednego zespo\u0142u przechodzi do innego zespo\u0142u?<\/b> W \u015brodowisku DevOps staje si\u0119 to norm\u0105, poniewa\u017c czasami osoba po prostu nie mo\u017ce zrozumie\u0107, czym zajmuje si\u0119 inna dziedzina specjalizacji. Przechodzi do innego dzia\u0142u, pracuje tam przez dwa tygodnie, aby stworzy\u0107 dla siebie map\u0119 orientacji i interakcji z tym dzia\u0142em.<\/p>\n

Czy mo\u017cna utworzy\u0107 komitet do zmian i co\u015b zmieni\u0107? <\/b>Czy potrzebna jest do tego silna r\u0119ka najwy\u017cszego kierownictwa i zarz\u0105dzenie? Niedawno napisa\u0142em na Facebooku, jak jeden ma\u0142o znany bank wprowadza narz\u0119dzia poprzez zarz\u0105dzenia: napisali zarz\u0105dzenie, wdra\u017camy przez rok, patrzymy, co si\u0119 dzieje. Oczywi\u015bcie to jest d\u0142ugie i smutne.<\/p>\n

Jak wa\u017cne jest dla mened\u017cer\u00f3w uzyskiwanie osobistych osi\u0105gni\u0119\u0107 bez uwzgl\u0119dnienia osi\u0105gni\u0119\u0107 firmy? <\/b><\/p>\n

Je\u015bli odpowiesz sobie na te pytania, stanie si\u0119 jasne, czy masz taki problem w swojej firmie.<\/p>\n

Infrastruktura jako kod<\/h2>\n

\nGdy ju\u017c ten problem zostanie rozwi\u0105zany, pierwsz\u0105 wa\u017cn\u0105 praktyk\u0105, bez kt\u00f3rej trudno jest posun\u0105\u0107 si\u0119 dalej w DevOps, jest infrastruktura jako kod<\/b>. <\/p>\n

Najcz\u0119\u015bciej infrastruktur\u0119 jako kod postrzega si\u0119 w ten spos\u00f3b:<\/p>\n

\u2013 Zautomatyzujmy wszystko w bash, pokryjmy si\u0119 skryptami, aby admini mieli mniej r\u0119cznej pracy!<\/i><\/p>\n

Ale to nie prawda.<\/p>\n

Infrastruktura jako kod oznacza, \u017ce IT-system, z kt\u00f3rym pracujesz, opisujesz w formie kodu, aby stale rozumie\u0107 jego stan.<\/p><\/blockquote>\n

\nWsp\u00f3lnie z innymi zespo\u0142ami tworzysz map\u0119 w formie kodu, kt\u00f3ra jest zrozumia\u0142a dla wszystkich, wed\u0142ug kt\u00f3rej mo\u017cna si\u0119 orientowa\u0107, nawigowa\u0107. Nie ma znaczenia, na czym to zrobiono \u2013 Chef, Ansible, Salt, czy u\u017cyto plik\u00f3w YAML w Kubernetes \u2013 nie ma r\u00f3\u017cnicy.<\/p>\n

Na konferencji kolega z 2GIS opowiada\u0142, jak stworzyli swoje wewn\u0119trzne narz\u0119dzie dla Kubernetes, kt\u00f3re opisuje struktur\u0119 poszczeg\u00f3lnych system\u00f3w. Aby opisa\u0107 500 system\u00f3w, potrzebowali oddzielnego narz\u0119dzia, kt\u00f3re generuje te opisy. Kiedy jest to opisane, ka\u017cdy mo\u017ce si\u0119 odnies\u0107 do siebie, monitorowa\u0107 zmiany, jak to zmieni\u0107 i poprawi\u0107, czego brakuje. <\/p>\n

Przyznajcie, \u017ce oddzielne skrypty bash zwykle nie daj\u0105 tego zrozumienia. W jednej z firm, w kt\u00f3rej pracowa\u0142em, istnia\u0142o nawet okre\u015blenie \u201eskrypt write only\u201d \u2013 kiedy skrypt jest napisany, a przeczyta\u0107 go ju\u017c nie mo\u017cna. My\u015bl\u0119, \u017ce to wam tak\u017ce jest znane.<\/p>\n

Infrastruktura jako kod to kod, kt\u00f3ry opisuje aktualny stan infrastruktury<\/b>. Nad tym kodem wsp\u00f3lnie pracuje wiele zespo\u0142\u00f3w produktowych, infrastrukturalnych i serwisowych, i co najwa\u017cniejsze, wszyscy musz\u0105 rozumie\u0107, jak ten kod w og\u00f3le dzia\u0142a.<\/p>\n

Kod jest wspierany zgodnie z najlepszymi praktykami pracy z kodem<\/b>: wsp\u00f3lne tworzenie, przegl\u0105d kodu, programowanie XP, testowanie, pull requesty, CI dla infrastruktury kodu \u2013 to wszystko jest warto\u015bciowe i mo\u017cna to zastosowa\u0107.<\/p>\n

Kod staje si\u0119 wsp\u00f3lnym j\u0119zykiem dla wszystkich in\u017cynier\u00f3w.<\/p><\/blockquote>\n

\nZmiana infrastruktury w kodzie nie zajmuje du\u017co czasu<\/b>. Tak, w kodzie infrastrukturalnym tak\u017ce mo\u017ce by\u0107 d\u0142ug technologiczny. Zwykle zespo\u0142y spotykaj\u0105 si\u0119 z nim p\u00f3\u0142tora roku po rozpocz\u0119ciu wdra\u017cania \u201einfrastruktury jako kod\u201d w formie zestawu skrypt\u00f3w lub nawet Ansible, kt\u00f3re pisz\u0105 jako spaghetti kod, a do tego jeszcze dorzucaj\u0105 skrypty bash do pieca! <\/p>\n

Wa\u017cne<\/b>: je\u015bli jeszcze nie pr\u00f3bowa\u0142e\u015b tego badziewia, zapami\u0119taj, \u017ce Ansible \u2014 to nie bash<\/b>! Uwa\u017cnie czytaj dokumentacj\u0119, dowiedz si\u0119, co na ten temat pisz\u0105.<\/p>\n

Infrastruktura jako kod \u2014 to podzia\u0142 kodu infrastrukturalnego na osobne warstwy.<\/p><\/blockquote>\n

\nW naszej firmie wyr\u00f3\u017cniamy 3 podstawowe warstwy, kt\u00f3re s\u0105 bardzo zrozumia\u0142e i proste, ale mo\u017ce ich by\u0107 wi\u0119cej. Mo\u017cesz spojrze\u0107 na sw\u00f3j kod infrastrukturalny i sprawdzi\u0107, czy spe\u0142niasz ten warunek. Je\u015bli \u017cadne warstwy nie s\u0105 wydzielone, nale\u017cy znale\u017a\u0107 czas i troch\u0119 zrefaktoryzowa\u0107.
\n\"Czym
\n
\nWarstwa podstawowa<\/b>\u00a0\u2014 to jak konfiguruje si\u0119 system operacyjny, kopie zapasowe i inne niskopoziomowe rzeczy, na przyk\u0142ad, jak uruchamiany jest Kubernetes na poziomie podstawowym.<\/p>\n

Poziom us\u0142ug<\/b>\u00a0\u2014 to te us\u0142ugi, kt\u00f3re udost\u0119pniasz programi\u015bcie: logowanie jako us\u0142uga, monitoring jako us\u0142uga, baza danych jako us\u0142uga, load balancer jako us\u0142uga, kolejka jako us\u0142uga, Continuous Delivery jako us\u0142uga \u2014 mn\u00f3stwo us\u0142ug, kt\u00f3re r\u00f3\u017cne zespo\u0142y mog\u0105 dostarcza\u0107 programowaniu. Wszystko to nale\u017cy opisa\u0107 w osobnych modu\u0142ach w Twoim systemie zarz\u0105dzania konfiguracj\u0105.<\/p>\n

Warstwa, w kt\u00f3rej tworzy si\u0119 aplikacje<\/b> i opisuje, jak b\u0119d\u0105 si\u0119 one uruchamia\u0107 na dw\u00f3ch poprzednich warstwach.<\/p>\n

Pytania kontrolne<\/h3>\n

\nCzy w Twojej firmie istnieje wsp\u00f3lny repozytorium infrastruktury? Czy kontrolujesz d\u0142ug technologiczny w infrastrukturze? Czy stosujesz praktyki rozwoju w repozytorium infrastruktury? Czy Twoja infrastruktura jest podzielona na warstwy? Mo\u017cna to zweryfikowa\u0107 zgodnie z schematem Base-service-APP. Jak trudno jest wprowadzi\u0107 zmian\u0119? <\/p>\n

Je\u015bli spotka\u0142e\u015b si\u0119 z sytuacj\u0105, \u017ce wprowadzenie zmian zajmowa\u0142o p\u00f3\u0142tora dnia, oznacza to, \u017ce masz do czynienia z d\u0142ugiem technologicznym i trzeba to rozwi\u0105za\u0107. Natkn\u0105\u0142e\u015b si\u0119 w\u0142a\u015bnie na pu\u0142apki d\u0142ugu technologicznego w kodzie infrastrukturalnym. Pami\u0119tam wiele takich przypadk\u00f3w, gdy zmiana jakiego\u015b CCTL wymaga\u0142a przepisania po\u0142owy kodu infrastrukturalnego, poniewa\u017c ch\u0119\u0107 do automatyzacji i kreatywno\u015b\u0107 doprowadzi\u0142y do tego, \u017ce wsz\u0119dzie pojawi\u0142y si\u0119 przeszkody, wszystkie r\u0119ce zosta\u0142y usuni\u0119te i konieczna jest refaktoryzacja.<\/p>\n

Ci\u0105g\u0142a dostawa<\/h2>\n

\nPodsumujmy debet z kredytem. Najpierw pojawia si\u0119 opis infrastruktury, kt\u00f3ry mo\u017ce by\u0107 do\u015b\u0107 podstawowy. Nie trzeba wszystkiego opisywa\u0107 szczeg\u00f3\u0142owo, ale jakie\u015b podstawowe om\u00f3wienie jest wymagane, aby m\u00f3c z tym pracowa\u0107. W przeciwnym razie nie jest jasne, na czym mo\u017cna dalej budowa\u0107 ci\u0105g\u0142e dostarczanie. Wszystkie te praktyki rozwijaj\u0105 si\u0119 r\u00f3wnocze\u015bnie, gdy przechodzicie do DevOps, ale nale\u017cy zacz\u0105\u0107 od zrozumienia, co posiadacie i jak tym zarz\u0105dza\u0107. To jest w\u0142a\u015bnie praktyka infrastruktury jako kodu.<\/p>\n

Po tym, jak sta\u0142o si\u0119 jasne, co posiadacie, jak tym zarz\u0105dza\u0107, zaczynacie my\u015ble\u0107, jak maksymalnie szybko dostarczy\u0107 kod dewelopera na produkcj\u0119. M\u00f3wi\u0119 tu o wsp\u00f3\u0142pracy z deweloperem \u2014 pami\u0119tamy o problemie \"studni\", czyli nie jest to co\u015b, co wymy\u015blaj\u0105 oddzielni ludzie, ale zesp\u00f3\u0142.<\/p>\n

Kiedy my\u00a0z Wan\u0105 Jewtuchowiczem<\/b> zobaczyli\u015bmy pierwsz\u0105 ksi\u0105\u017ck\u0119 Jezza Hembla<\/b> i grupy autor\u00f3w \u201eContinuous Delivery\u201d<\/b>, kt\u00f3ra ukaza\u0142a si\u0119 w 2009 roku, d\u0142ugo zastanawiali\u015bmy si\u0119, jak przet\u0142umaczy\u0107 jej tytu\u0142 na j\u0119zyk polski. Chcieli\u015bmy przet\u0142umaczy\u0107 jako \u201eCi\u0105g\u0142e dostarczanie\u201d, ale niestety przet\u0142umaczyli\u015bmy jako \u201eNiekontrolowana dostawa\u201d. Wydaje mi si\u0119, \u017ce w naszej nazwie jest co\u015b takiego polskiego, z impetem.<\/p>\n

Ci\u0105g\u0142e dostarczanie \u2014 to znaczy<\/h3>\n

\nKod znajduj\u0105cy si\u0119 w repozytorium produktu zawsze mo\u017ce by\u0107 dostarczony na produkcj\u0119<\/b>. Mo\u017ce nie by\u0107 dostarczony, ale zawsze jest na to gotowy. W zwi\u0105zku z tym, zawsze piszecie kod z trudnym do wyja\u015bnienia poczuciem pewnego niepokoju w dolnej cz\u0119\u015bci plec\u00f3w. Pojawia si\u0119 to uczucie, gdy wdra\u017cacie kod infrastrukturalny. To poczucie pewnego niepokoju powinno by\u0107 obecne \u2014 wywo\u0142uje procesy my\u015blowe, kt\u00f3re pozwalaj\u0105 pisa\u0107 kod nieco inaczej. Powinno by\u0107 to uwzgl\u0119dnione w zasadach wewn\u0105trz rozwoju.<\/p>\n

Aby ci\u0105gle dostarcza\u0107, potrzebny jest format artefaktu, kt\u00f3ry przechodzi przez platform\u0119 infrastrukturaln\u0105. <\/b>Je\u015bli wrzucacie do platformy infrastrukturalnej r\u00f3\u017cne formaty \"odpady \u017cyciowe\", staje si\u0119 ona nieu\u0142adzona, trudna w utrzymaniu, pojawia si\u0119 problem d\u0142ugu technicznego. Format artefaktu nale\u017cy ujednolici\u0107 \u2014 to te\u017c wsp\u00f3lne zadanie: wszyscy musz\u0105 si\u0119 zebra\u0107, pomy\u015ble\u0107 wsp\u00f3lnie i wymy\u015bli\u0107 ten format.<\/p>\n

Artefakt jest ci\u0105gle doskonalony i dostosowywany do \u015brodowiska produkcyjnego w trakcie przechodzenia przez pipeline dostaw. <\/b>Kiedy artefakt porusza si\u0119 przez pipeline, non stop spotyka si\u0119 z r\u00f3\u017cnymi wyzwaniami, kt\u00f3re przypominaj\u0105 te, z kt\u00f3rymi mo\u017ce si\u0119 zetkn\u0105\u0107 artefakt w produkcji. Je\u015bli w klasycznym procesie rozwijania robi to administrator systemu podczas wdro\u017cenia, to w procesie DevOps dzieje si\u0119 to nieustannie: tutaj przeszed\u0142 przez r\u00f3\u017cne testy, tam zosta\u0142 wrzucony do klastra Kubernetes, kt\u00f3ry jest bardziej lub mniej podobny do produkcji, a tu nagle wystartowano testy obci\u0105\u017ceniowe.<\/p>\n

To przypomina gr\u0119 Pac-Man \u2013 artefakt przechodzi przez jak\u0105\u015b histori\u0119. Wa\u017cne jest przy tym kontrolowanie, czy kod faktycznie realizuje t\u0119 histori\u0119 i jest jako\u015b zwi\u0105zany z twoj\u0105 produkcj\u0105. Historie z produkcji mo\u017cna w\u0142\u0105czy\u0107 w proces Continuous Delivery: by\u0142o tak, \u017ce co\u015b si\u0119 zepsu\u0142o, wi\u0119c zaprogramujmy ten scenariusz w systemie. Za ka\u017cdym razem kod przejdzie przez ten scenariusz, i nie napotkasz tej samej problemu nast\u0119pnym razem. Dowiesz si\u0119 o tym znacznie wcze\u015bniej, zanim dotrze do klienta.<\/p>\n

R\u00f3\u017cne strategie wdro\u017ce\u0144. <\/b>Na przyk\u0142ad, u\u017cywasz test\u00f3w AB lub wdro\u017ce\u0144 kanaryjnych, aby r\u00f3\u017cnie 'testowa\u0107' kod na r\u00f3\u017cnych klientach, zbiera\u0107 informacje o tym, jak dzia\u0142a kod, i znacznie wcze\u015bniej, zanim zostanie wdro\u017cony dla 100 milion\u00f3w u\u017cytkownik\u00f3w.<\/p>\n

\u201eCi\u0105g\u0142e dostarczanie\u201d wygl\u0105da tak.<\/p>\n

\"Czym
\n<\/p>\n

Proces dostarczania Dev, CI, Test, PreProd, Prod \u2013 to nie s\u0105 oddzielne \u015brodowiska, to etapy lub stacje z nieod\u0142\u0105czonymi kwotami, przez kt\u00f3re przemieszczany jest tw\u00f3j artefakt.<\/p><\/blockquote>\n

\nJe\u015bli masz kod infrastrukturalny, kt\u00f3ry opisany jest jako Base Service APP, to pomaga nie zapomnie\u0107 o wszystkich scenariuszach<\/b>, i zapisa\u0107 je r\u00f3wnie\u017c w postaci kodu dla tego artefaktu, promowa\u0107 artefakt<\/b> i zmienia\u0107 go w trakcie jego drogi.<\/p>\n

Pytania do samosprawdzania<\/h3>\n

\nCzas od opisu funkcji do wdro\u017cenia na produkcji w 95% przypadk\u00f3w jest kr\u00f3tszy ni\u017c tydzie\u0144? Czy jako\u015b\u0107 artefaktu poprawia si\u0119 na ka\u017cdym etapie pipeline? Czy istnieje historia, przez kt\u00f3r\u0105 przechodzi? Czy u\u017cywasz r\u00f3\u017cnych strategii wdro\u017ce\u0144?<\/p>\n

Je\u015bli wszystkie odpowiedzi brzmi\u0105 tak, to jeste\u015b niesamowicie \u015bwietny! Napisz odpowiedzi w komentarzach \u2013 ucieszy mnie to).<\/p>\n

Informacje zwrotne<\/h3>\n

\nTo najtrudniejsza praktyka ze wszystkich. Na konferencji DevOpsConf kolega z Infobip, opowiadaj\u0105c o niej, nieco pl\u0105ta\u0142 si\u0119 w s\u0142owach, poniewa\u017c to naprawd\u0119 bardzo skomplikowana praktyka dotycz\u0105ca monitorowania absolutnie wszystkiego!<\/p>\n

\"Czym
\n
\nNa przyk\u0142ad, dawno temu, kiedy pracowa\u0142em w Qik, zrozumieli\u015bmy, \u017ce musimy monitorowa\u0107 wszystko. Zrobili\u015bmy to i w Zabbix mieli\u015bmy 150 000 element\u00f3w, kt\u00f3re by\u0142y monitorowane non stop. To by\u0142o przera\u017caj\u0105ce, dyrektor techniczny kr\u0119ci\u0142 palcem przy skroni:<\/p>\n

\u2014 Ch\u0142opaki, po co tak katujecie serwer niewiadomo czym?<\/i><\/p>\n

Ale p\u00f3\u017aniej wydarzy\u0142o si\u0119 co\u015b, co pokaza\u0142o, \u017ce to naprawd\u0119 \u015bwietna strategia.<\/p>\n

Jedna z us\u0142ug zacz\u0119\u0142a regularnie pada\u0107. Pocz\u0105tkowo nie pada\u0142a, co ciekawe, do kodu nie wprowadzano \u017cadnych zmian, poniewa\u017c to by\u0142 podstawowy broker, kt\u00f3ry praktycznie nie mia\u0142 funkcjonalno\u015bci biznesowej \u2014 po prostu przesy\u0142a\u0142 wiadomo\u015bci pomi\u0119dzy poszczeg\u00f3lnymi us\u0142ugami. Us\u0142uga nie zmienia\u0142a si\u0119 przez 4 miesi\u0105ce, a nagle zacz\u0119\u0142a pada\u0107 z b\u0142\u0119dem \u201eSegmentation fault\u201d.<\/p>\n

Byli\u015bmy w szoku, otworzyli\u015bmy nasze wykresy w Zabbix i okaza\u0142o si\u0119, \u017ce p\u00f3\u0142tora tygodnia temu znacznie zmieni\u0142o si\u0119 zachowanie zapyta\u0144 w API serwisie, kt\u00f3ry korzysta z tego brokera. Potem zauwa\u017cyli\u015bmy, \u017ce zmieni\u0142a si\u0119 cz\u0119stotliwo\u015b\u0107 wysy\u0142ania okre\u015blonego typu wiadomo\u015bci. Po chwili dowiedzieli\u015bmy si\u0119, \u017ce to klienci android. Zapyta\u0142em:<\/p>\n

\u2014 Ch\u0142opaki, co si\u0119 u was wydarzy\u0142o p\u00f3\u0142tora tygodnia temu?<\/i><\/p>\n

W odpowiedzi us\u0142yszeli\u015bmy ciekaw\u0105 histori\u0119 o tym, \u017ce zmienili UI. Ma\u0142o kto od razu powie, \u017ce zmieni\u0142 bibliotek\u0119 HTTP. Dla klient\u00f3w android to jak wymiana myd\u0142a w \u0142azience \u2014 po prostu tego nie pami\u0119taj\u0105. W ko\u0144cu, po 40 minutach rozmowy, dowiedzieli\u015bmy si\u0119, \u017ce jednak zmienili bibliotek\u0119 HTTP, a w niej zmieni\u0142y si\u0119 domy\u015blne czasy. To spowodowa\u0142o, \u017ce zmieni\u0142o si\u0119 zachowanie ruchu na serwerze API, co doprowadzi\u0142o do sytuacji, kt\u00f3ra wywo\u0142a\u0142a wy\u015bcig wewn\u0105trz brokera i zacz\u0119\u0142a on pada\u0107.<\/p>\n

Bez g\u0142\u0119bokiego monitoringu to by\u0142oby zupe\u0142nie niemo\u017cliwe do wykrycia.<\/b>. Je\u015bli w organizacji istnieje jeszcze problem \"studni\", gdzie ka\u017cdy przerzuca odpowiedzialno\u015b\u0107 na drugiego, to mo\u017ce to trwa\u0107 latami. Po prostu restartujesz serwer, poniewa\u017c rozwi\u0105zanie problemu jest niemo\u017cliwe. Kiedy monitorujesz, \u015bledzisz, rejestrujesz wszystkie zdarzenia, kt\u00f3re masz, i u\u017cywasz monitorowania jako testowania \u2014 piszesz kod i od razu wskazujesz, jak go monitorowa\u0107, r\u00f3wnie\u017c w formie kodu (ju\u017c mamy infrastruktur\u0119 jako kod), wszystko staje si\u0119 jasne jak na d\u0142oni. Nawet tak skomplikowane problemy s\u0105 \u0142atwe do \u015bledzenia.<\/p>\n

\"Czym
\n<\/p>\n

Zbieraj wszelkie informacje o tym, co dzieje si\u0119 z artefaktem na ka\u017cdym etapie procesu dostarczania \u2014 nie w produkcji.<\/p><\/blockquote>\n

\nMonitoring wrzu\u0107 do CI, a tam ju\u017c b\u0119d\u0105 widoczne jakie\u015b podstawowe rzeczy. P\u00f3\u017aniej b\u0119dziesz je widzie\u0107 zar\u00f3wno w Test, jak i w PredProd, oraz w testach obci\u0105\u017ceniowych. Zbieraj informacje na wszystkich etapach, przy czym nie tylko metryki, statystyki, ale i logi: jak aplikacja zosta\u0142a wdro\u017cona, anomalie \u2014 zbieraj wszystko. <\/p>\n

W przeciwnym razie b\u0119dzie trudno si\u0119 po\u0142apa\u0107. Ju\u017c m\u00f3wi\u0142em, \u017ce DevOps to wi\u0119ksza z\u0142o\u017cono\u015b\u0107. Aby poradzi\u0107 sobie z t\u0105 z\u0142o\u017cono\u015bci\u0105, trzeba mie\u0107 dobr\u0105 analityk\u0119.<\/b>.<\/p>\n

Pytania do samooceny.<\/h3>\n

\nCzy Tw\u00f3j monitoring i logowanie to narz\u0119dzie rozwoju dla Ciebie?<\/b> Czy Twoi programi\u015bci, w tym Ty, kiedy pisz\u0105 kod, my\u015bl\u0105 o tym, jak go monitorowa\u0107?<\/p>\n

Czy dowiadujesz si\u0119 o problemach od klient\u00f3w? Czy rozumiesz klienta lepiej dzi\u0119ki monitorowaniu i logowaniu?<\/b> Czy rozumiesz system lepiej dzi\u0119ki monitorowaniu i logowaniu?<\/b> Czy zmieniasz system tylko dlatego, \u017ce zauwa\u017cy\u0142e\u015b, \u017ce trend w systemie ro\u015bnie i rozumiesz, \u017ce jeszcze 3 tygodnie i wszystko upadnie? <\/p>\n

Kiedy masz te trzy komponenty, mo\u017cesz pomy\u015ble\u0107 o tym, jaka jest w Twojej firmie platforma infrastrukturalna.<\/p>\n

Platforma infrastrukturalna. <\/h2>\n

\nChodzi o to, \u017ce to nie jest zestaw rozproszonych narz\u0119dzi, kt\u00f3re ma ka\u017cda firma.<\/p>\n

Sens platformy infrastrukturalnej polega na tym, \u017ce wszystkie zespo\u0142y korzystaj\u0105 z tych narz\u0119dzi i rozwijaj\u0105 je wsp\u00f3lnie.<\/p><\/blockquote>\n

\nJasne jest, \u017ce s\u0105 osobne zespo\u0142y, kt\u00f3re odpowiadaj\u0105 za rozw\u00f3j poszczeg\u00f3lnych cz\u0119\u015bci platformy infrastrukturalnej. Ale odpowiedzialno\u015b\u0107 za rozw\u00f3j, funkcjonowanie i promocj\u0119 platformy infrastrukturalnej spoczywa na ka\u017cdym in\u017cynierze. Na poziomie wewn\u0119trznym staje si\u0119 to wsp\u00f3lnym narz\u0119dziem<\/b>. <\/p>\n

Wszystkie zespo\u0142y rozwijaj\u0105 platform\u0119 infrastrukturaln\u0105, traktuj\u0105c j\u0105 ostro\u017cnie jak w\u0142asne IDE<\/b>. W swoim IDE instalujesz r\u00f3\u017cne wtyczki, aby wszystko wygl\u0105da\u0142o \u0142adnie i dzia\u0142a\u0142o szybko, konfigurujesz skr\u00f3ty klawiszowe. Kiedy otwierasz Sublime, Atom lub Visual Studio Code, pojawiaj\u0105 si\u0119 b\u0142\u0119dy kodu i rozumiesz, \u017ce praca staje si\u0119 praktycznie niemo\u017cliwa, od razu czujesz smutek i biegasz naprawi\u0107 swoje IDE.<\/p>\n

Dok\u0142adnie w ten sam spos\u00f3b traktuj swoj\u0105 platform\u0119 infrastrukturaln\u0105. Je\u015bli rozumiesz, \u017ce co\u015b jest nie tak, sk\u0142adaj zg\u0142oszenie, je\u015bli nie mo\u017cesz naprawi\u0107 samodzielnie. Je\u015bli to co\u015b prostego \u2014 poprawiaj samodzielnie, wysy\u0142aj pull request \u2014 ch\u0142opaki to rozwa\u017c\u0105, dodadz\u0105. To nieco inne podej\u015bcie do in\u017cynieryjnego warsztatu w g\u0142owie programisty.<\/p>\n

Platforma infrastrukturalna zapewnia przesy\u0142anie artefaktu od dewelopera do klienta z ci\u0105g\u0142ym podnoszeniem jako\u015bci<\/b>. W IP zaprogramowany jest zestaw historii, kt\u00f3re dziej\u0105 si\u0119 z kodem w produkcji. W trakcie lat rozwoju tych historii staje si\u0119 bardzo du\u017co, cz\u0119\u015b\u0107 z nich jest unikalna i odnosi si\u0119 tylko do ciebie \u2014 nie mo\u017cna ich znale\u017a\u0107 w sieci. <\/p>\n

W tym momencie platforma infrastrukturalna staje si\u0119 twoim przewag\u0105 konkurencyjn\u0105<\/b>, poniewa\u017c zawiera elementy, kt\u00f3rych nie ma w narz\u0119dziach konkurencji. Im g\u0142\u0119bsza twoja IP, tym wi\u0119ksza twoja przewaga konkurencyjna w kontek\u015bcie Time-to-market. Pojawia si\u0119 tutaj problem vendor lock<\/b>: mo\u017cesz wybra\u0107 sobie cudz\u0105 platform\u0119, ale korzystaj\u0105c z cudzych do\u015bwiadcze\u0144, nie b\u0119dziesz rozumie\u0107, jak bardzo s\u0105 one odpowiednie dla ciebie. Tak, nie ka\u017cda firma mo\u017ce zbudowa\u0107 platform\u0119 na miar\u0119 Amazonu. To trudna granica, gdzie do\u015bwiadczenie firmy jest relevantne dla jej pozycji na rynku, i nie mo\u017cna dopu\u015bci\u0107 do vendor lock. O tym r\u00f3wnie\u017c warto pomy\u015ble\u0107.<\/p>\n

Schemat<\/h3>\n

\nTo podstawowy schemat platformy infrastrukturalnej, kt\u00f3ry pomo\u017ce ci zorganizowa\u0107 wszystkie praktyki i procesy w firmie DevOps.<\/p>\n

\"Czym
\n
\nPrzyjrzyjmy si\u0119, z czego si\u0119 sk\u0142ada.<\/p>\n

System orkiestracji zasob\u00f3w<\/b>, kt\u00f3ry zapewnia CPU, pami\u0119\u0107, dysk aplikacjom i innym us\u0142ugom. Na tym z kolei \u2014 us\u0142ugi niskiego poziomu<\/b>: monitorowanie, logowanie, CI\/CD Engine, magazyn artefakt\u00f3w, infrastruktura jako kod system\u00f3w.<\/p>\n

Us\u0142ugi wy\u017cszego poziomu<\/b>: baza danych jako us\u0142uga, kolejki jako us\u0142uga, Load Balance jako us\u0142uga, resizing obrazk\u00f3w jako us\u0142uga, Big Data fabryka jako us\u0142uga. Na tym\u00a0wszystkim\u00a0\u2014 pipeline, kt\u00f3ry dostarcza stale modyfikowany kod do twojego klienta<\/b>.<\/p>\n

Otrzymujesz informacje o tym, jak twoje oprogramowanie dzia\u0142a u klienta, zmieniasz, ponownie dostarczasz ten kod, uzyskujesz informacje \u2014 i tak stale rozwijasz zar\u00f3wno infrastruktur\u0119, jak i swoje oprogramowanie.<\/p>\n

Na schemacie delivery pipeline sk\u0142ada si\u0119 z wielu stacji. Ale to jest zasadnicza schemat, kt\u00f3ry pokazano jako przyk\u0142ad \u2014 nie nale\u017cy go powtarza\u0107 jeden do jednego. Stacje wsp\u00f3\u0142dzia\u0142aj\u0105 z us\u0142ugami jako us\u0142ugami \u2014 ka\u017cdy element platformy niesie swoj\u0105 histori\u0119: jak przydzielane s\u0105 zasoby, jak aplikacja jest uruchamiana, dzia\u0142a z zasobami, monitorowana, zmieniana.<\/p>\n

Wa\u017cne jest zrozumienie, \u017ce ka\u017cda cz\u0119\u015b\u0107 platformy niesie histori\u0119, i pytanie siebie \u2014 jak\u0105 histori\u0119 niesie ten element, mo\u017ce warto go wyrzuci\u0107 i zast\u0105pi\u0107 zewn\u0119trzn\u0105 us\u0142ug\u0105. Na przyk\u0142ad, czy mo\u017cna zamiast elementu postawi\u0107 Okmeter? By\u0107 mo\u017ce ch\u0142opaki ju\u017c rozwin\u0119li t\u0119 ekspertyz\u0119 znacznie bardziej ni\u017c my. Ale mo\u017ce te\u017c nie \u2014 by\u0107 mo\u017ce mamy unikaln\u0105 ekspertyz\u0119, musimy postawi\u0107 Prometheus i rozwija\u0107 to dalej.<\/p>\n

Budowanie platformy<\/h3>\n

\nTo skomplikowany proces komunikacyjny. Kiedy masz podstawowe praktyki, uruchamiasz komunikacj\u0119 mi\u0119dzy r\u00f3\u017cnymi in\u017cynierami i specjalistami, kt\u00f3rzy opracowuj\u0105 wymagania i standardy, i stale je zmieniaj\u0105 w odniesieniu do r\u00f3\u017cnych narz\u0119dzi i podej\u015b\u0107. Tutaj wa\u017cna jest kultura, kt\u00f3ra istnieje w DevOps.<\/p>\n

\"Czym
\nZ kultur\u0105 wszystko jest bardzo proste \u2014 to wsp\u00f3\u0142praca i komunikacja<\/b>, czyli ch\u0119\u0107 pracy na wsp\u00f3lnym polu razem, ch\u0119\u0107 wsp\u00f3lnego korzystania z jednego narz\u0119dzia. Nie ma w tym \u017cadnej nauki rakietowej \u2014 wszystko jest bardzo proste, banalne. Na przyk\u0142ad, wszyscy \u017cyjemy w klatce schodowej i dbamy o jej czysto\u015b\u0107 \u2014 taki poziom kultury.<\/p>\n

A co u was?<\/h3>\n

\nZnowu pytania, kt\u00f3re mo\u017cesz sobie zada\u0107.<\/p>\n

Czy infrastruktura jest wyr\u00f3\u017cniona? Kto odpowiada za jej rozw\u00f3j? Czy rozumiesz przewagi konkurencyjne swojej infrastruktury?<\/p>\n

Te pytania nale\u017cy zadawa\u0107 sobie na bie\u017c\u0105co. Je\u015bli co\u015b mo\u017cna przenie\u015b\u0107 na zewn\u0119trzne us\u0142ugi \u2013 nale\u017cy to zrobi\u0107. Je\u015bli zewn\u0119trzna us\u0142uga zaczyna blokowa\u0107 twoje dzia\u0142ania, powiniene\u015b zbudowa\u0107 system wewn\u0119trznie.<\/p>\n

A wi\u0119c, DevOps\u2026<\/h2>\n

\n\u2026 to z\u0142o\u017cony system, kt\u00f3ry musi zawiera\u0107:<\/p>\n