{"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\/sv\/blog\/administrirovanie\/chto-takoe-devops","title":{"rendered":"Vad \u00e4r DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Definitionen av DevOps \u00e4r mycket komplexa, s\u00e5 varje g\u00e5ng m\u00e5ste diskussionen b\u00f6rja om fr\u00e5n b\u00f6rjan. Endast p\u00e5 Habr finns det tusen publiceringar om detta \u00e4mne. Men om du l\u00e4ser detta, vet du s\u00e4kert vad DevOps \u00e4r. F\u00f6r eftersom jag inte g\u00f6r det. Hej, jag heter Alexander Titov (@osminog<\/a><\/noindex><\/b>), och vi kommer bara att prata om DevOps och jag kommer att dela med mig av min erfarenhet.<\/p>\n

\"Vad
\n
\nJag har l\u00e4nge funderat p\u00e5 hur jag ska g\u00f6ra min ber\u00e4ttelse anv\u00e4ndbar, s\u00e5 h\u00e4r kommer det att finnas m\u00e5nga fr\u00e5gor - s\u00e5dana som jag st\u00e4ller till mig sj\u00e4lv, och s\u00e5dana som jag st\u00e4ller till kunderna i v\u00e5rt f\u00f6retag. Genom att svara p\u00e5 dessa fr\u00e5gor blir f\u00f6rst\u00e5elsen b\u00e4ttre. Jag kommer att f\u00f6rklara varf\u00f6r DevOps \u00e4r viktigt ur min synvinkel, vad det inneb\u00e4r, \u00e5terigen fr\u00e5n min position, och hur man kan f\u00f6rst\u00e5 om ni r\u00f6r er mot DevOps, \u00e5terigen fr\u00e5n min synvinkel. Den sista punkten kommer att st\u00e4llas genom fr\u00e5gor. Genom att svara p\u00e5 dem till mig sj\u00e4lv kan ni f\u00f6rst\u00e5 om ert f\u00f6retag r\u00f6r sig mot DevOps eller om det finns problem.
\n<\/a><\/noindex>
\n

\r\n \"Spela\r\n
<\/div>\r\n <\/div><\/center>
\nEn tid gick jag p\u00e5 v\u00e5gorna av sammanslagningar och f\u00f6rv\u00e4rv. F\u00f6rst arbetade jag p\u00e5 den lilla start-upen Qik, sedan k\u00f6ptes den av det n\u00e5got st\u00f6rre f\u00f6retaget Skype, som sedan k\u00f6ptes av det \u00e4nnu st\u00f6rre f\u00f6retaget Microsoft. I det \u00f6gonblicket fick jag insikt om hur uppfattningen om DevOps f\u00f6r\u00e4ndras i f\u00f6retag av olika storlekar. Efter det blev jag intresserad av att se DevOps ur marknadens perspektiv, och vi, tillsammans med kollegor, grundade f\u00f6retaget Express 42. I \u00f6ver 6 \u00e5r har vi navigerat p\u00e5 marknaden.<\/p>\n

F\u00f6rutom allt detta \u00e4r jag en av organisat\u00f6rerna av DevOps Moscow-samh\u00e4llet och arrang\u00f6r av DevOps-Days 2017, men 2018 organiserade jag inte. Express 42 jobbar med m\u00e5nga f\u00f6retag. Vi utvecklar DevOps d\u00e4r, ser hur det g\u00e5r till, drar slutsatser, analyserar, ber\u00e4ttar v\u00e5ra slutsatser f\u00f6r alla, utbildar folk i DevOps-praktiker. Sammanfattningsvis v\u00e4xer vi p\u00e5 det h\u00e4r omr\u00e5det vad g\u00e4ller erfarenhet och expertis.<\/p>\n

Varf\u00f6r DevOps<\/h2>\n

\nDen f\u00f6rsta fr\u00e5gan som alltid pl\u00e5gar alla \u00e4r - varf\u00f6r? M\u00e5nga tror att DevOps bara handlar om automatisering eller liknande saker, som redan existerar i varje f\u00f6retag.<\/p>\n

- Vi hade Continuous Integration - det betyder att vi redan hade DevOps, och varf\u00f6r beh\u00f6vs all denna babblan? D\u00e4r borta roar de sig, men h\u00e4r st\u00f6r de v\u00e5rt arbete!<\/i><\/p>\n

Under 9 years of community and methodology development, it has become clear that this is not just marketing hype, but it is still not entirely clear why it is needed. Like any tool or process, DevOps has specific goals that it ultimately addresses.<\/p>\n

This is all related to the fact that the world is changing. It is moving away from the enterprise approach where companies move straight towards their dreams, as our St. Petersburg classic sang, from point A to point B according to a specific strategy, with a dedicated structure built for that purpose. <\/p>\n

\"Vad
\n<\/p>\n

In principle, IT should be structured under this approach. Here, IT is used solely for automating processes.<\/p><\/blockquote>\n

\nAutomation does not change often, because when a company is on a well-trodden path \u2014 why change anything? If it works, don't touch it. Now in the world, approaches are changing, and the one called Agile indicates that the endpoint B is not immediately visible.<\/p>\n

\"Vad
\n
\nAs a company navigates the market and works with clients, it is constantly researching the market and changing its endpoint B. Moreover, the more often a company shifts its direction, the more successful it ultimately becomes as it captures more market niches.<\/p>\n

An interesting company illustrates this strategy, which I recently learned about. One Box Shave \u2014 a subscription service for delivering razors and shaving supplies in a box. They can customize their \"box\" for different clients. This is handled by specific software that then sends the order to a Korean factory producing the product.<\/p>\n

This product was bought by Unilever for $1 billion. It is now competing with Gillette and has taken a significant share of consumers in the American market. One Box Shave says:<\/p>\n

\"Four blades? Are you serious? Why do you need that\u2014it does not improve shaving quality at all. A carefully selected cream, fragrance, and a quality razor with two blades address many more issues than those silly four blades from Gillette! Are we soon going to have ten?\"<\/i><\/p>\n

Thus, the world is changing. Unilever claims to have a cool IT system that makes this possible. Ultimately, it looks like the concept of Time-to-market<\/b>, which has been discussed by many.<\/p>\n

\"Vad
\n
\nBetydelsen av Time-to-market handlar inte om hur ofta vi deployar. Vi kan ofta deploya, men releasecyklerna kan vara l\u00e5nga. Om vi l\u00e4gger tre m\u00e5nader l\u00e5nga releasecykler ovanp\u00e5 varandra, flyttande dem med en vecka, s\u00e5 verkar det som om f\u00f6retaget deployar en g\u00e5ng i veckan. Men fr\u00e5n id\u00e9 till slutlig implementation tar det tre m\u00e5nader.<\/p>\n

Time-to-market handlar om att minimera tiden fr\u00e5n id\u00e9 till slutlig implementation.<\/p><\/blockquote>\n

\nI det h\u00e4r fallet interagerar programvaran med marknaden. S\u00e5 i One Box Shave interagerar webbplatsen med kunden. De har inga s\u00e4ljare - bara en webbplats d\u00e4r bes\u00f6karen klickar och l\u00e4mnar \u00f6nskem\u00e5l. D\u00e4rf\u00f6r m\u00e5ste man st\u00e4ndigt publicera n\u00e5got nytt p\u00e5 webbplatsen och uppdatera den i enlighet med \u00f6nskem\u00e5len. Till exempel, i Sydkorea rakar man sig inte som i Ryssland, och de f\u00f6redrar dofter som inte \u00e4r av tall utan till exempel morotsvanilj.<\/p>\n

Eftersom det kr\u00e4vs att snabbt \u00e4ndra inneh\u00e5llet p\u00e5 webbplatsen, f\u00f6r\u00e4ndras programvaruutvecklingen avsev\u00e4rt. Genom programvaran m\u00e5ste vi ta reda p\u00e5 vad kunden vill ha. Tidigare fick vi veta detta p\u00e5 olika omv\u00e4gar, till exempel genom aff\u00e4rsadministration. Sedan designade vi, lade in kraven i IT-systemet, och allt var bra. Nu \u00e4r det annorlunda - programvaran designas av alla som \u00e4r involverade i processen, inklusive ingenj\u00f6rer, eftersom de f\u00e5r insikter om hur marknaden fungerar genom tekniska specifikationer och ocks\u00e5 delar sina insikter med aff\u00e4rssidan.<\/p>\n

Till exempel, i f\u00f6retaget Qik fick vi pl\u00f6tsligt veta att folk verkligen gillar att ladda upp kontaktlistor till servern, och de gav oss en app. Vi t\u00e4nkte inte p\u00e5 detta fr\u00e5n b\u00f6rjan. I ett klassiskt f\u00f6retag skulle alla ha bed\u00f6mt att det var en bugg eftersom det inte stod i specifikationen att det skulle fungera bra och det var dessutom genomf\u00f6rt p\u00e5 ett hastigt s\u00e4tt, de skulle ha st\u00e4ngt av funktionen och sagt: \"Det beh\u00f6vs inte, det viktigaste \u00e4r att den grundl\u00e4ggande funktionaliteten fungerar.\" Men ett teknologiskt f\u00f6retag ser en m\u00f6jlighet i detta och b\u00f6rjar \u00e4ndra programvaran i enlighet med det.<\/p>\n

\"Vad
\n
\n\u00c5r 1968 formulerade den kloka killen Melvin Conway f\u00f6ljande id\u00e9.<\/p>\n

Organisationen som skapar ett system \u00e4r begr\u00e4nsad av designen som speglar kommunikationsstrukturen i denna organisation.<\/p><\/blockquote>\n

\nF\u00f6r att producera system av en annan typ beh\u00f6ver ni dessutom ha en kommunikationsstruktur inom f\u00f6retaget av en annan typ. Om ni har en topp-ner hierarkisk kommunikationsstruktur, kommer det inte att till\u00e5ta er att skapa system som kan s\u00e4kerst\u00e4lla en mycket h\u00f6g Time-to-market.<\/p>\n

L\u00e4s mer om Conway-lagen<\/a><\/noindex> kan via l\u00e4nkar<\/a><\/noindex>. Den \u00e4r viktig f\u00f6r att f\u00f6rst\u00e5 kulturen eller filosofin bakom DevOps, eftersom det enda som grundl\u00e4ggande f\u00f6r\u00e4ndras inom DevOps \u00e4r just kommunikationsstrukturen mellan teamen.<\/b>.<\/p>\n

Ur processens synvinkel har alla faser: analys, utveckling, testning, drift, i DevOps varit linj\u00e4ra.\"Vad
\nI DevOps p\u00e5g\u00e5r alla dessa processer samtidigt.<\/p>\n

\"Vad
\n
\nTime-to-market kan endast uppn\u00e5s p\u00e5 detta s\u00e4tt. F\u00f6r personer som har arbetat i den gamla processen kan detta verka ganska futuristiskt, och \u00f6verlag inte s\u00e5 tilltalande.<\/p>\n

S\u00e5 varf\u00f6r beh\u00f6vs DevOps?<\/h3>\n

\nF\u00f6r utvecklingen av digitala produkter.<\/b>Om ni inte har en digital produkt i ert f\u00f6retag, beh\u00f6vs inte DevOps - detta \u00e4r mycket viktigt.<\/p>\n

DevOps \u00f6vervinner de hastighetsbegr\u00e4nsningar som \u00e4r f\u00f6rknippade med en sekventiell produktionsmodell.<\/b>I den sker alla processer samtidigt.<\/p>\n

Komplexiteten \u00f6kar.<\/b> N\u00e4r DevOps-evangelister s\u00e4ger att det kommer att bli enklare att sl\u00e4ppa programvara med DevOps - det \u00e4r nonsens.<\/p>\n

Med DevOps blir allt bara mer komplext.<\/p><\/blockquote>\n

\nP\u00e5 konferensen p\u00e5 Avitos monter kunde man se hur man deployar en Docker-container - en orealistisk uppgift. Komplexiteten blir \u00f6verv\u00e4ldigande, man m\u00e5ste jonglera med m\u00e5nga bollar samtidigt.<\/p>\n

DevOps f\u00f6r\u00e4ndrar helt processen och organisationen i f\u00f6retaget<\/b>\u00a0\u2013 snarare f\u00f6r\u00e4ndrar inte DevOps, utan den digitala produkten. F\u00f6r att n\u00e5 DevOps m\u00e5ste man \u00e4nd\u00e5 f\u00f6r\u00e4ndra hela denna process.<\/p>\n

Fr\u00e5gor f\u00f6r specialisten<\/h3>\n

\nOch vad har ni? Fr\u00e5gor som ni kan st\u00e4lla till er sj\u00e4lva n\u00e4r ni arbetar i f\u00f6retaget och utvecklas som specialist.<\/p>\n

Har ni en strategi f\u00f6r att skapa en digital produkt?<\/b> Om ni har det \u2013 bra. Det betyder att ert f\u00f6retag r\u00f6r sig mot DevOps.<\/p>\n

Skapar ert f\u00f6retag redan en digital produkt?<\/b> Det inneb\u00e4r att ni kan ta ett steg upp\u00e5t till, engagera er i intressantare verksamhet \u2013 ur DevOps-perspektiv. Jag h\u00e4nvisar endast till detta perspektiv.<\/p>\n

\u00c4r ert f\u00f6retag en av marknadsledarna inom en nisch med digital produkt?<\/b> Spotify, Yandex, Uber \u2013 f\u00f6retag som just nu \u00e4r i framkant av teknologisk utveckling.<\/p>\n

St\u00e4ll dessa fr\u00e5gor till dig sj\u00e4lv, och om alla svar \u00e4r negativa, \u00e4r det kanske b\u00e4st att du inte sysslar med DevOps p\u00e5 det h\u00e4r f\u00f6retaget. Men om DevOps verkligen intresserar dig, kanske\u2026 du borde \u00f6verv\u00e4ga att byta f\u00f6retag? Om ditt f\u00f6retag vill g\u00e5 \u00f6ver till DevOps, men du svarade \"Nej\" p\u00e5 alla fr\u00e5gor, p\u00e5minner det om den h\u00e4r vackra nosh\u00f6rningen som aldrig kommer att f\u00f6r\u00e4ndras.<\/p>\n

\"Vad
\n<\/p>\n

Organisationen<\/h2>\n

\nSom jag redan har n\u00e4mnt, enligt Conway\u2019s lag, f\u00f6r\u00e4ndras organisationen inom f\u00f6retaget. Jag b\u00f6rjar med vad som hindrar DevOps fr\u00e5n att tr\u00e4nga in i f\u00f6retaget just ur organisatoriskt perspektiv.<\/p>\n

Problemet med \"siloer\"<\/h3>\n

\nDet engelska ordet \"Silo\" \u00f6vers\u00e4tts h\u00e4r till ryska som \"\u043a\u043e\u043b\u043e\u0434\u0435\u0446\" (brunn). Problemet h\u00e4r handlar om att det inte finns n\u00e5got informationsutbyte mellan teamen.<\/b>. Varje team gr\u00e4ver djupt inom sin egen expertis, utan att bygga en gemensam karta d\u00e4r man kan orientera sig.<\/p>\n

Det p\u00e5minner lite om en person som just har anl\u00e4nt till Moskva och \u00e4nnu inte kan navigera p\u00e5 tunnelbanekartan. Moskva-inv\u00e5nare brukar k\u00e4nna till sitt omr\u00e5de bra, och i hela Moskva orienterar de sig efter tunnelbanekartan. N\u00e4r du kommer till Moskva f\u00f6r f\u00f6rsta g\u00e5ngen har du inte den f\u00e4rdigheten, och du \u00e4r bara desorienterad.<\/p>\n

DevOps erbjuder att g\u00e5 igenom denna desorienteringsperiod och tillsammans med alla avdelningar bygga en gemensam interaktionskarta.<\/p><\/blockquote>\n

\nTv\u00e5 faktorer hindrar detta.<\/p>\n

Konsekvenserna av f\u00f6retagets ledningssystem.<\/b> Det \u00e4r uppbyggt av separata hierarkiska \"siloer\". Till exempel finns det vissa KPI:er i f\u00f6retag som st\u00f6der detta system. \u00c5 andra sidan hindras det av m\u00e4nniskors t\u00e4nkande, d\u00e4r det kan vara sv\u00e5rt att g\u00e5 utanf\u00f6r sin egen expertis och orientera sig i hela systemet. Det \u00e4r helt enkelt obekv\u00e4mt. T\u00e4nk dig att du hamnat p\u00e5 Bangkok flygplats \u2013 d\u00e4r \u00e4r det sv\u00e5rt att snabbt orientera sig. Det \u00e4r ocks\u00e5 sv\u00e5rt att navigera i DevOps, och d\u00e4rf\u00f6r s\u00e4ger folk att man m\u00e5ste hitta en guide f\u00f6r att komma dit.<\/p>\n

Men det viktigaste \u00e4r att problemet med \"siloer\" f\u00f6r en ingenj\u00f6r som har anammat DevOps-andan och l\u00e4st Fowler och massor av andra b\u00f6cker, uttrycker sig i att \"siloer\" hindrar att \"uppenbara\" saker g\u00f6rs<\/b>. Vi samlas ofta efter DevOps Moscow, pratar med varandra, och folk klagar:<\/p>\n

\u2014 Vi ville bara starta CI, men det visade sig att ledningen inte beh\u00f6vde det.<\/i><\/p>\n

Det beror just p\u00e5 att\u00a0CI <\/b>och\u00a0Continuous Delivery-processen<\/b> ligger p\u00e5 gr\u00e4nsen till m\u00e5nga expertiser. Genom att inte \u00f6vervinna problemet med \u00abbrunnar\u00bb p\u00e5 organisationsniv\u00e5 kommer det inte att g\u00e5 att g\u00f6ra framsteg, oavsett vad ni g\u00f6r och hur sorgligt det \u00e4n kan verka.<\/p>\n

\"Vad
\n
\nVarje deltagare i processen inom f\u00f6retaget: backend- och frontend-utvecklare, testning, DBA, drift, n\u00e4tverk, gr\u00e4ver p\u00e5 sin egen sida, medan ingen har en gemensam karta, utom f\u00f6rvaltaren som p\u00e5 n\u00e5got s\u00e4tt \u00f6verser dem och styr med metoden \u00abdela och h\u00e4rska\u00bb.<\/p>\n

M\u00e4nniskor k\u00e4mpar f\u00f6r olika stj\u00e4rnor eller flaggor, varje person f\u00f6rdjupar sin egen expertis.<\/p><\/blockquote>\n

\nSom ett resultat, n\u00e4r uppgiften att koppla samman allt detta och bygga en gemensam pipeline uppst\u00e5r, och det inte l\u00e4ngre handlar om att k\u00e4mpa f\u00f6r stj\u00e4rnor och flaggor, uppst\u00e5r fr\u00e5gan \u2013 vad ska man g\u00f6ra \u00f6verhuvudtaget? Man m\u00e5ste p\u00e5 n\u00e5got s\u00e4tt komma \u00f6verens, och hur man g\u00f6r det, l\u00e4rde ingen oss i skolan. Vi har l\u00e4rt oss redan i skolan: \u00e5ttonde klass \u2013 wow! \u2013 j\u00e4mf\u00f6rt med sjunde klass! H\u00e4r \u00e4r det samma.<\/p>\n

\u00c4r det likadant i ert f\u00f6retag?<\/h3>\n

\nF\u00f6r att kontrollera detta kan man st\u00e4lla sig f\u00f6ljande fr\u00e5gor.<\/p>\n

Anv\u00e4nder teamen gemensamma verktyg och bidrar de med f\u00f6r\u00e4ndringar i dessa gemensamma verktyg?<\/p>\n

\u041d\u0430\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0447\u0430\u0441\u0442\u043e \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u043f\u0435\u0440\u0435\u0444\u043e\u0440\u043c\u0438\u0440\u0443\u044e\u0442\u0441\u044f\u00a0\u2014 \u043e\u0434\u043d\u0438 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u044b \u0438\u0437\u00a0\u043e\u0434\u043d\u043e\u0439 \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u044f\u0442 \u0432\u00a0\u0434\u0440\u0443\u0433\u0443\u044e \u043a\u043e\u043c\u0430\u043d\u0434\u0443?<\/b> \u0418\u043c\u0435\u043d\u043d\u043e \u0432\u00a0DevOps-\u0441\u0440\u0435\u0434\u0435 \u044d\u0442\u043e \u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442\u0441\u044f \u043d\u043e\u0440\u043c\u0430\u043b\u044c\u043d\u044b\u043c, \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0438\u043d\u043e\u0433\u0434\u0430 \u0447\u0435\u043b\u043e\u0432\u0435\u043a \u043f\u0440\u043e\u0441\u0442\u043e \u043d\u0435\u00a0\u043c\u043e\u0436\u0435\u0442 \u043f\u043e\u043d\u044f\u0442\u044c, \u0447\u0435\u043c \u0437\u0430\u043d\u0438\u043c\u0430\u0435\u0442\u0441\u044f \u0434\u0440\u0443\u0433\u0430\u044f \u0437\u043e\u043d\u0430 \u044d\u043a\u0441\u043f\u0435\u0440\u0442\u0438\u0437\u044b. \u041e\u043d\u00a0\u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0438\u0442 \u0432\u00a0\u0434\u0440\u0443\u0433\u043e\u0439 \u043e\u0442\u0434\u0435\u043b, \u0434\u0432\u0435 \u043d\u0435\u0434\u0435\u043b\u044c\u043a\u0438 \u0442\u0430\u043c \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u0447\u0442\u043e\u0431\u044b \u0441\u043e\u0437\u0434\u0430\u0442\u044c \u0434\u043b\u044f \u0441\u0435\u0431\u044f \u043a\u0430\u0440\u0442\u0443 \u043e\u0440\u0438\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0438\u00a0\u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u0441\u00a0\u044d\u0442\u0438\u043c \u043e\u0442\u0434\u0435\u043b\u043e\u043c.<\/p>\n

Kan en kommitt\u00e9 bildas f\u00f6r att g\u00f6ra f\u00f6r\u00e4ndringar och \u00e4ndra n\u00e5got? <\/b>Eller kr\u00e4vs det en stark hand fr\u00e5n den h\u00f6gsta ledningen och ett beslut? Nyss skrev jag p\u00e5 Facebook om hur en relativt ok\u00e4nd bank genom beslut implementerar verktyg: de skrev ett beslut, implementerade i ett \u00e5r och ser vad som h\u00e4nder. Det \u00e4r naturligtvis l\u00e5ngsamt och sorgligt.<\/p>\n

Hur viktigt \u00e4r det f\u00f6r chefer att f\u00e5 personliga prestationer oavsett f\u00f6retagets prestationer? <\/b><\/p>\n

Om ni svarar p\u00e5 dessa fr\u00e5gor blir det tydligare om ni har detta problem i f\u00f6retaget.<\/p>\n

Infrastruktur som kod<\/h2>\n

\nN\u00e4r detta problem \u00e4r l\u00f6st \u00e4r den f\u00f6rsta viktiga praktiken, utan vilken det \u00e4r sv\u00e5rt att avancera ytterligare inom DevOps, att infrastruktur som kod<\/b>. <\/p>\n

Oftast uppfattas infrastruktur som kod s\u00e5 h\u00e4r:<\/p>\n

\u2014 L\u00e5t oss automatisera allt med bash, \u00f6ver\u00f6sa oss med skript s\u00e5 att administrat\u00f6rerna f\u00e5r mindre manuellt arbete!<\/i><\/p>\n

Men s\u00e5 \u00e4r det inte.<\/p>\n

Infrastruktur som kod inneb\u00e4r att du beskriver den IT-system du arbetar med i form av kod, f\u00f6r att st\u00e4ndigt f\u00f6rst\u00e5 dess tillst\u00e5nd.<\/p><\/blockquote>\n

\nTillsammans med andra team skapar du en karta i form av kod som alla kan f\u00f6rst\u00e5, som kan anv\u00e4ndas f\u00f6r att orientera och navigera. Oavsett vilket verktyg som anv\u00e4nds \u2013 Chef, Ansible, Salt, eller om YAML-filer anv\u00e4nds i Kubernetes \u2013 spelar det ingen roll.<\/p>\n

P\u00e5 konferensen ber\u00e4ttade en kollega fr\u00e5n 2GIS hur de skapade sin interna l\u00f6sning f\u00f6r Kubernetes, som beskriver strukturen f\u00f6r varje enskilt system. F\u00f6r att beskriva 500 system beh\u00f6vde de ett s\u00e4rskilt verktyg som genererade denna beskrivning. N\u00e4r denna beskrivning finns, kan alla kontrollera med varandra, \u00f6vervaka \u00e4ndringar, hur det kan \u00e4ndras och f\u00f6rb\u00e4ttras, och vad som saknas. <\/p>\n

F\u00f6rst\u00e5s ger separata bash-skript vanligtvis inte denna insyn. P\u00e5 ett av de f\u00f6retag jag arbetade p\u00e5 fanns det till och med ett namn som \"write only\"-skript \u2013 n\u00e4r skriptet \u00e4r skrivet g\u00e5r det inte att l\u00e4sa. Jag tror att ni ocks\u00e5 k\u00e4nner igen detta.<\/p>\n

Infrastruktur som kod \u00e4r Kod som beskriver det aktuella tillst\u00e5ndet f\u00f6r infrastrukturen<\/b>. Denna kod hanteras gemensamt av m\u00e5nga produkt-, infrastrukturs- och serviceteam, och viktigast av allt, alla m\u00e5ste f\u00f6rst\u00e5 hur denna kod faktiskt fungerar.<\/p>\n

Koden underh\u00e5lls enligt b\u00e4sta praxis f\u00f6r kodhantering<\/b>: gemensam utveckling, kodgranskning, XP-programmering, testning, pull requests, CI f\u00f6r infrastrukturkod \u2013 allt detta \u00e4r v\u00e4rdefullt och kan anv\u00e4ndas.<\/p>\n

Koden blir ett gemensamt spr\u00e5k f\u00f6r alla ingenj\u00f6rer.<\/p><\/blockquote>\n

\nAtt \u00e4ndra infrastrukturen i koden tar inte mycket tid<\/b>. Ja, det kan finnas teknisk skuld \u00e4ven i infrastrukturkoden. Vanligtvis m\u00f6ter team denna skuld efter ungef\u00e4r ett och ett halvt \u00e5r efter att de b\u00f6rjat implementera \"infrastruktur som kod\" i form av en massa skript eller till och med Ansible, som de skriver som spaghettikod, och sedan sl\u00e4nger in bash-skript i grytan! <\/p>\n

Det \u00e4r viktigt<\/b>: om ni inte har provat denna skr\u00e4pa \u00e4n, kom ih\u00e5g att Ansible \u00e4r inte bash<\/b>! L\u00e4s noga igenom dokumentationen, studera vad som faktiskt skrivs om det h\u00e4r.<\/p>\n

Infrastruktur som kod \u2014 det handlar om att dela upp infrastrukturell kod i separata lager.<\/p><\/blockquote>\n

\nI v\u00e5rt f\u00f6retag identifierar vi tre grundl\u00e4ggande lager som \u00e4r tydliga och enkla, men det kan finnas fler. Du kan titta p\u00e5 din infrastrukturella kod och se om du uppfyller detta villkor eller inte. Om inga lager har identifierats, b\u00f6r du ta tid att refaktorera lite.
\n\"Vad
\n
\nGrundlager<\/b>\u00a0\u2014 det handlar om hur operativsystemet konfigureras, s\u00e4kerhetskopior och andra l\u00e5g niv\u00e5 saker, till exempel hur Kubernetes distribueras p\u00e5 grundniv\u00e5.<\/p>\n

Tj\u00e4nstlager<\/b>\u00a0\u2014 det \u00e4r de tj\u00e4nster som du tillhandah\u00e5ller utvecklaren: loggning som tj\u00e4nst, \u00f6vervakning som tj\u00e4nst, databas som tj\u00e4nst, load balancer som tj\u00e4nst, k\u00f6 som tj\u00e4nst, Continuous Delivery som tj\u00e4nst \u2014 en m\u00e4ngd tj\u00e4nster som olika team kan erbjuda utvecklingen. Allt detta m\u00e5ste beskrivas i separata moduler i ditt konfigurationshanteringssystem.<\/p>\n

Lagret d\u00e4r applikationer g\u00f6rs<\/b> och d\u00e4r det beskrivs hur de ska distribueras ovanp\u00e5 de tv\u00e5 f\u00f6reg\u00e5ende lagren.<\/p>\n

Kontrollfr\u00e5gor<\/h3>\n

\nHar ditt f\u00f6retag ett gemensamt infrastrukturellt arkiv? Kontrollerar ni teknisk skuld i infrastrukturen? Anv\u00e4nder ni utvecklingspraxis i det infrastrukturella arkivet? \u00c4r er infrastruktur uppdelad i lager? Man kan verifiera med schemat Base-service-APP. Hur sv\u00e5rt \u00e4r det att g\u00f6ra en f\u00f6r\u00e4ndring? <\/p>\n

Om du har st\u00f6tt p\u00e5 situationen d\u00e4r en f\u00f6r\u00e4ndring tog en och en halv dag, betyder det att ni har f\u00e5tt teknisk skuld som ni m\u00e5ste arbeta med. Du har precis st\u00f6tt p\u00e5 en f\u00e4lla av teknisk skuld i den infrastrukturella koden. Jag minns m\u00e5nga s\u00e5dana historier d\u00e4r f\u00f6r att \u00e4ndra n\u00e5got CCTL m\u00e5ste man skriva om h\u00e4lften av den infrastrukturella koden, eftersom kreativitet och viljan att automatisera allt har lett till att allt \u00e4r \u00f6verbelastat, alla handgrepp har tagits bort och refaktorisering beh\u00f6vs.<\/p>\n

Kontinuerlig leverans<\/h2>\n

\nVi sammanfattar debet och kredit. F\u00f6rst finns en beskrivning av infrastrukturen, som kan vara ganska grundl\u00e4ggande. Det \u00e4r inte n\u00f6dv\u00e4ndigt att beskriva allt i detalj, men en viss grundl\u00e4ggande beskrivning kr\u00e4vs f\u00f6r att ni ska kunna arbeta med detta. Annars \u00e4r det oklart hur man ska genomf\u00f6ra kontinuerlig leverans. Alla dessa metoder inf\u00f6rs samtidigt n\u00e4r ni kommer till DevOps, men man m\u00e5ste b\u00f6rja med att f\u00f6rst\u00e5 vad man har och hur man hanterar det. Det \u00e4r just denna praktik f\u00f6r infrastruktur som kod.<\/p>\n

N\u00e4r ni har f\u00f6rst\u00e5tt vad ni har och hur ni kan hantera det, b\u00f6rjar ni fundera p\u00e5 hur utvecklarens kod snabbt kan skickas till produktion. Jag menar tillsammans med utvecklaren \u2013 kom ih\u00e5g problemet med \"brunnar\", det vill s\u00e4ga det \u00e4r inte bara enskilda personer som kommer p\u00e5 detta, utan det g\u00f6rs som ett team.<\/p>\n

N\u00e4r vi\u00a0s\u00e5g Vanya Evtuchevich<\/b> f\u00f6rsta boken Jez Humble<\/b> och en grupp f\u00f6rfattare \"Continuous Delivery\"<\/b>, som kom ut 2009, funderade vi l\u00e4nge p\u00e5 hur vi skulle \u00f6vers\u00e4tta titeln till svenska. Vi ville \u00f6vers\u00e4tta den som \"St\u00e4ndigt leverera\", men tyv\u00e4rr \u00f6versatte vi det som \"Kontinuerlig leverans\". Jag tycker att det finns n\u00e5got s\u00e5dant ryskt i v\u00e5r titel, med kraft.<\/p>\n

St\u00e4ndigt leverera \u2013 det betyder<\/h3>\n

\nKoden som ligger i produktrepositoriet kan alltid rullas ut till produktion<\/b>. Den kan kanske inte rullas ut, men den \u00e4r alltid redo f\u00f6r det. D\u00e4rf\u00f6r skriver ni alltid kod med en sv\u00e5rf\u00f6rklarad k\u00e4nsla av viss oro i nedre delen av ryggen. Denna k\u00e4nsla av oro uppst\u00e5r ofta n\u00e4r man rullar ut infrastrukturkod. Det \u00e4r just denna k\u00e4nsla av oro som m\u00e5ste vara n\u00e4rvarande \u2013 den v\u00e4cker mentala processer som g\u00f6r att man kan skriva kod p\u00e5 ett lite annat s\u00e4tt. Detta b\u00f6r dokumenteras i reglerna inom utvecklingen.<\/p>\n

F\u00f6r att st\u00e4ndigt kunna leverera beh\u00f6ver man ett artefaktformat som g\u00e5r igenom den infrastrukturella plattformen. <\/b>Om ni sl\u00e4nger olika typer av \"avfallsprodukter\" \u00f6ver den infrastrukturella plattformen, s\u00e5 blir den icke-enhetlig, sv\u00e5r att underh\u00e5lla och det uppst\u00e5r ett tekniskt skuldproblem. Artefaktformatet m\u00e5ste j\u00e4mnas ut \u2013 detta \u00e4r ocks\u00e5 en kollektiv uppgift: man m\u00e5ste samlas, t\u00e4nka tillsammans och komma p\u00e5 detta format.<\/p>\n

Artefakten f\u00f6rb\u00e4ttras kontinuerligt och anpassas till produktionsmilj\u00f6n under hela leveranspipeline processen. <\/b>N\u00e4r artefakten r\u00f6r sig genom pipelinen, st\u00f6ter den hela tiden p\u00e5 olika utmaningar som liknar dem som artefakten m\u00f6ter n\u00e4r ni sl\u00e4pper den till produktion. Om en systemadministrat\u00f6r hanterar detta i klassisk utveckling, s\u00e5 h\u00e4nder det kontinuerligt i DevOps-processen: h\u00e4r pr\u00f6var de den med olika tester, d\u00e4r kastas den in i ett Kubernetes-kluster som mer eller mindre liknar produktionen, och pl\u00f6tsligt k\u00f6rs belastningstestning.<\/p>\n

Det p\u00e5minner om spelet Pac-Man - artefakten genomg\u00e5r en historia. Det \u00e4r viktigt att \u00f6vervaka om koden faktiskt genomg\u00e5r en historia som \u00e4r relaterad till er produktion. Historier om produktion kan integreras i Continuous Delivery-processen: det har varit s\u00e5 tidigare n\u00e4r n\u00e5got har kraschat, l\u00e5t oss programmera det scenariot direkt i systemet. Varje g\u00e5ng kommer koden ocks\u00e5 att genomg\u00e5 detta scenario, och ni kommer att uppt\u00e4cka problemet mycket tidigare innan det n\u00e5r era kunder.<\/p>\n

Olika distributionsstrategier. <\/b>Till exempel kan ni anv\u00e4nda A\/B-testning eller kanarief\u00e5gelsutdelningar f\u00f6r att p\u00e5 olika s\u00e4tt \"k\u00e4nna av\" koden hos olika kunder, f\u00e5 information om hur koden fungerar och mycket tidigare \u00e4n n\u00e4r den distribueras till 100 miljoner anv\u00e4ndare.<\/p>\n

\"Kontinuerlig leverans\" ser ut s\u00e5 h\u00e4r.<\/p>\n

\"Vad
\n<\/p>\n

Leveransprocessen Dev, CI, Test, PreProd, Prod \u00e4r inte en separat milj\u00f6, det \u00e4r steg eller stationer med icke-br\u00e4nnbara summor d\u00e4r er artefakt passerar.<\/p><\/blockquote>\n

\nOm ni har infrastrukturkod som beskrivs som Base Service APP, hj\u00e4lper den att inte gl\u00f6mma alla scenarier<\/b>, och att ocks\u00e5 skriva ner dem i form av kod f\u00f6r denna artefakt, att f\u00f6ra artefakten fram\u00e5t<\/b> och att f\u00f6r\u00e4ndra den under sin v\u00e4g.<\/p>\n

Fr\u00e5gor f\u00f6r sj\u00e4lvkontroll<\/h3>\n

\n\u00c4r tiden fr\u00e5n beskrivning av funktionen till distribution i produktion i 95 % av fallen mindre \u00e4n en vecka? F\u00f6rb\u00e4ttras kvaliteten p\u00e5 artefakten vid varje steg i pipelinen? Finns det en historia som den genomg\u00e5r? Anv\u00e4nder ni olika distributionsstrategier?<\/p>\n

Om alla svar \u00e4r ja, d\u00e5 \u00e4r ni otroligt duktiga! Skriv svaren i kommentarerna - jag ser fram emot dem).<\/p>\n

Feedback<\/h3>\n

\nDet h\u00e4r \u00e4r den mest komplexa praktiken av alla. Under konferensen DevOpsConf blev en kollega fr\u00e5n Infobip lite os\u00e4ker i sina ord n\u00e4r han pratade om detta, eftersom det verkligen \u00e4r en mycket komplex praktik om vad man faktiskt beh\u00f6ver \u00f6vervaka \u00f6verhuvudtaget!<\/p>\n

\"Vad
\n
\nTill exempel, f\u00f6r l\u00e4nge sedan, n\u00e4r jag arbetade p\u00e5 Qik och vi ins\u00e5g att vi verkligen beh\u00f6vde \u00f6vervaka allt. Vi gjorde det, och vi hade 150 000 objekt i Zabbix som st\u00e4ndigt \u00f6vervakades. Det var skr\u00e4mmande, teknisk chef snurrade fingret vid tungan:<\/p>\n

\u2014 Grabbar, varf\u00f6r misshandlar ni servern med n\u00e5got oklart?<\/i><\/p>\n

Men sedan intr\u00e4ffade en h\u00e4ndelse som visade att detta verkligen \u00e4r en riktigt cool strategi.<\/p>\n

En av tj\u00e4nsterna b\u00f6rjade st\u00e4ndigt falla. Ursprungligen f\u00f6ll den inte, intressant nog, eftersom ingen kod lades till, eftersom det var en grundl\u00e4ggande broker d\u00e4r det praktiskt taget inte fanns n\u00e5gon aff\u00e4rsfunktionalitet \u2013 den skickade bara meddelanden mellan olika tj\u00e4nster. Tj\u00e4nsten hade inte f\u00f6r\u00e4ndrats p\u00e5 4 m\u00e5nader, och pl\u00f6tsligt b\u00f6rjade den falla med ett felmeddelande \"Segmentation fault\".<\/p>\n

Vi var i chock, vi \u00f6ppnade v\u00e5ra grafer i Zabbix, och det visade sig att beteendet hos f\u00f6rfr\u00e5gningar i API-tj\u00e4nsten som anv\u00e4nder denna broker hade f\u00f6r\u00e4ndrats kraftigt f\u00f6r en och en halv vecka sedan. Senare s\u00e5g vi att frekvensen f\u00f6r att skicka vissa typer av meddelanden hade f\u00f6r\u00e4ndrats. Efter\u00e5t fick vi veta att det var android-klienterna. Vi fr\u00e5gade:<\/p>\n

\u2014 Grabbar, vad h\u00e4nde f\u00f6r en och en halv vecka sedan?<\/i><\/p>\n

Som svar h\u00f6rde vi en intressant ber\u00e4ttelse om att de hade gjort om UI. Vem skulle i s\u00e5 fall omedelbart s\u00e4ga att de bytte HTTP-bibliotek? F\u00f6r android-klienter \u00e4r det som att byta tv\u00e5l i badrummet \u2013 de gl\u00f6mmer helt enkelt bort det. Resultatet blev att efter 40 minuter av samtal kom vi fram till att de faktiskt hade bytt HTTP-bibliotek, och dess standardtidsinst\u00e4llningar hade \u00e4ndrats. Det ledde till att beteendet hos trafiken p\u00e5 API-servern f\u00f6r\u00e4ndrades, vilket ledde till situationen som orsakade en race condition inuti brokern, och den b\u00f6rjade falla.<\/p>\n

Utan djupg\u00e5ende \u00f6vervakning \u00e4r det helt om\u00f6jligt att avsl\u00f6ja detta.<\/b>. Om det finns ett problem med \"brunnar\" i organisationen, d\u00e4r alla skyller p\u00e5 varandra, kan det p\u00e5g\u00e5 i flera \u00e5r. Du startar bara om servern eftersom det \u00e4r om\u00f6jligt att l\u00f6sa problemet. N\u00e4r du \u00f6vervakar, sp\u00e5rar och f\u00f6ljer alla h\u00e4ndelser som du har, och anv\u00e4nder \u00f6vervakning som testning \u2013 skriver kod och anger genast hur den ska \u00f6vervakas, ocks\u00e5 i form av kod (vi har redan infrastruktur som kod), blir allt kristallklart. \u00c4ven s\u00e5dana komplexa problem kan enkelt sp\u00e5ras.<\/p>\n

\"Vad
\n<\/p>\n

Samla all information om vad som h\u00e4nder med artefakten i varje steg av leveransprocessen \u2013 inte i produktion.<\/p><\/blockquote>\n

\nLadda upp \u00f6vervakningen p\u00e5 CI, och d\u00e4r kommer n\u00e5gra grundl\u00e4ggande saker att synas. Du kommer att se dem \u00e4ven i Test, PredProd och vid belastningstestning. Samla information p\u00e5 alla stadier, och inte bara metrik, statistik utan \u00e4ven loggar: hur applikationen rullas ut, anomalier \u2013 samla allt. <\/p>\n

Annars blir det sv\u00e5rt att f\u00f6rst\u00e5. Jag har redan sagt att DevOps inneb\u00e4r en st\u00f6rre komplexitet. F\u00f6r att hantera denna komplexitet beh\u00f6ver man ha god analys.<\/b>.<\/p>\n

Fr\u00e5gor f\u00f6r egenkontroll.<\/h3>\n

\n\u00c4r din \u00f6vervakning och loggning ett utvecklingsverktyg f\u00f6r er?<\/b> T\u00e4nker dina utvecklare, inklusive du sj\u00e4lv, n\u00e4r de skriver kod p\u00e5 hur den ska \u00f6vervakas?<\/p>\n

F\u00e5r ni veta om problem fr\u00e5n kunder? F\u00f6rst\u00e5r ni kunderna b\u00e4ttre genom \u00f6vervakning och loggning?<\/b> F\u00f6rst\u00e5r ni systemet b\u00e4ttre genom \u00f6vervakning och loggning?<\/b> \u00c4ndrar ni systemet bara f\u00f6r att ni ser att trenden i systemet \u00f6kar och f\u00f6rst\u00e5r att om tre veckor kommer allt att kollapsa? <\/p>\n

N\u00e4r ni har dessa tre komponenter kan ni fundera p\u00e5 vilken infrastrukturplattform ni har i f\u00f6retaget.<\/p>\n

Infrastrukturplattform. <\/h2>\n

\nPo\u00e4ngen \u00e4r inte att det \u00e4r en upps\u00e4ttning av skilda verktyg som finns i varje f\u00f6retag.<\/p>\n

Po\u00e4ngen med infrastrukturplattformen \u00e4r att alla team anv\u00e4nder dessa verktyg och utvecklar dem tillsammans.<\/p><\/blockquote>\n

\nDet \u00e4r klart att det finns separata team som ansvarar f\u00f6r utvecklingen av specifika delar av infrastrukturplattformen. Men ansvaret f\u00f6r utvecklingen, funktionaliteten och fr\u00e4mjandet av infrastrukturplattformen ligger p\u00e5 varje ingenj\u00f6r. P\u00e5 en intern niv\u00e5 blir detta ett gemensamt verktyg<\/b>. <\/p>\n

Alla team utvecklar infrastrukturplattformen och behandlar den varsamt som sin egen IDE<\/b>. I din IDE installerar du olika plugins f\u00f6r att allt ska se bra och snabbt ut, och du konfigurerar genv\u00e4gar. N\u00e4r du \u00f6ppnar Sublime, Atom eller Visual Studio Code, hur koden kraschar och du inser att det \u00e4r n\u00e4stan om\u00f6jligt att arbeta, blir du genast nedslagen och springer f\u00f6r att fixa din IDE.<\/p>\n

Behandla din infrastrukturplattform p\u00e5 samma s\u00e4tt. Om du uppt\u00e4cker att n\u00e5got \u00e4r fel med den, l\u00e4mna en f\u00f6rfr\u00e5gan om hj\u00e4lp om du inte kan fixa det sj\u00e4lv. Men om det \u00e4r n\u00e5got enkelt - fixa det sj\u00e4lv och skicka en pull request - teamet kommer att granska och l\u00e4gga till det. Det \u00e4r en n\u00e5got annan syn p\u00e5 ingenj\u00f6rsverktyg i utvecklarens huvud.<\/p>\n

Infrastrukturplattformen m\u00f6jligg\u00f6r \u00f6verf\u00f6ring av artefakten fr\u00e5n utvecklingen till klienten med st\u00e4ndiga kvalitetsf\u00f6rb\u00e4ttringar<\/b>. P\u00e5 IP finns en upps\u00e4ttning ber\u00e4ttelser programmerade som h\u00e4nder med koden i produktion. Under \u00e5ren av utveckling har det blivit v\u00e4ldigt m\u00e5nga av dessa ber\u00e4ttelser; en del av dem \u00e4r unika och handlar bara om dig - de g\u00e5r inte att hitta p\u00e5 n\u00e4tet. <\/p>\n

Vid denna tidpunkt blir infrastrukturplattformen din konkurrensf\u00f6rdel<\/b>, eftersom den har inslag som saknas i konkurrentens verktyg. Ju djupare din IP \u00e4r, desto st\u00f6rre \u00e4r din konkurrensf\u00f6rdel i termer av Time-to-market. H\u00e4r uppst\u00e5r problemet med vendor lock<\/b>: du kan ta en annan plattform, men genom att anv\u00e4nda n\u00e5gon annans erfarenhet kommer du inte att f\u00f6rst\u00e5 hur relevant det \u00e4r f\u00f6r dig. Ja, inte alla f\u00f6retag kan bygga en plattform som Amazon. Det \u00e4r en sv\u00e5r gr\u00e4ns d\u00e4r ett f\u00f6retags erfarenhet \u00e4r relevant f\u00f6r dess position p\u00e5 marknaden, och att sl\u00e4ppa in vendor lock \u00e4r inte tillr\u00e5dligt. Det \u00e4r ocks\u00e5 n\u00e5got som \u00e4r viktigt att t\u00e4nka p\u00e5.<\/p>\n

Diagram<\/h3>\n

\nDetta \u00e4r den grundl\u00e4ggande schemat f\u00f6r infrastrukturplattformen, som kommer hj\u00e4lpa dig att etablera alla praxis och processer i ett DevOps-f\u00f6retag.<\/p>\n

\"Vad
\n
\nL\u00e5t oss titta p\u00e5 vad den best\u00e5r av.<\/p>\n

Resursorkestreringssystemet<\/b>, som tillhandah\u00e5ller CPU, minne och disk f\u00f6r applikationerna och andra tj\u00e4nster. Ovanp\u00e5 detta finns det tj\u00e4nster p\u00e5 l\u00e5g niv\u00e5<\/b>: \u00f6vervakning, loggning, CI\/CD-motor, lagring av artefakter, infrastruktur som kod-system.<\/p>\n

Tj\u00e4nster p\u00e5 h\u00f6gre niv\u00e5<\/b>: databas som en tj\u00e4nst, k\u00f6er som en tj\u00e4nst, Load Balance som en tj\u00e4nst, resizing av bilder som en tj\u00e4nst, Big Data fabrik som en tj\u00e4nst. \u00d6ver detta - pipeline som st\u00e4ndigt levererar modifierad kod till din klient<\/b>.<\/p>\n

Du f\u00e5r information om hur din programvara fungerar hos kunden, \u00e4ndrar, levererar denna kod igen, f\u00e5r information - och s\u00e5 utvecklar du st\u00e4ndigt b\u00e5de din infrastrukturplattform och din programvara.<\/p>\n

I schemat best\u00e5r leveranspipeline av m\u00e5nga steg. Men detta \u00e4r en principskiss som ges som exempel - du beh\u00f6ver inte \u00e5terskapa den exakt. Stegen interagerar med tj\u00e4nster som tj\u00e4nster - varje byggsten i plattformen b\u00e4r sin egen historia: hur resurser tilldelas, hur applikationen startas, arbetar med resurser, \u00f6vervakas och f\u00f6r\u00e4ndras.<\/p>\n

Det \u00e4r viktigt att f\u00f6rst\u00e5 att varje del av plattformen b\u00e4r en historia, och att fr\u00e5ga sig - vilken historia b\u00e4r denna byggsten, kanske b\u00f6r den sl\u00e4ngas och ers\u00e4ttas med en extern tj\u00e4nst. Till exempel, kan vi ist\u00e4llet f\u00f6r byggstenen s\u00e4tta in Okmeter? Kanske har de redan utvecklat denna expertis mycket mer \u00e4n vi. Men kanske inte - kanske har vi unik expertis, och vi beh\u00f6ver s\u00e4tta in Prometheus och utveckla detta vidare.<\/p>\n

Att bygga en plattform<\/h3>\n

\nDetta \u00e4r en komplex kommunikationsprocess. N\u00e4r du har grundl\u00e4ggande praxis, startar du kommunikationen mellan olika ingenj\u00f6rer och specialister, som utvecklar krav och standarder, och st\u00e4ndigt f\u00f6r\u00e4ndrar dem till olika verktyg och metoder. H\u00e4r \u00e4r kulturen viktig, som finns i DevOps.<\/p>\n

\"Vad
\nMed kultur \u00e4r allt v\u00e4ldigt enkelt - det \u00e4r samarbete och kommunikation<\/b>, det vill s\u00e4ga en vilja att arbeta p\u00e5 gemensam mark med varandra, en vilja att tillsammans beh\u00e4rska ett verktyg. Det finns ingen rocket science h\u00e4r - allt \u00e4r v\u00e4ldigt enkelt, banalt. Till exempel, vi alla bor i en trappuppg\u00e5ng och uppr\u00e4tth\u00e5ller dess renlighet - en s\u00e5dan niv\u00e5 av kultur.<\/p>\n

Och hur \u00e4r det med er?<\/h3>\n

\n\u00c5terigen fr\u00e5gor som du kan st\u00e4lla dig sj\u00e4lv.<\/p>\n

\u00c4r infrastrukturplattformen avskild? Vem ansvarar f\u00f6r dess utveckling? F\u00f6rst\u00e5r ni konkurrensf\u00f6rdelarna med er infrastrukturplattform?<\/p>\n

Dessa fr\u00e5gor m\u00e5ste man st\u00e4ndigt st\u00e4lla sig sj\u00e4lv. Om n\u00e5got kan outsourcas till externa tj\u00e4nster \u2014 b\u00f6r det g\u00f6ras; om den externa tj\u00e4nsten b\u00f6rjar blockera din framfart, m\u00e5ste man bygga ett system inifr\u00e5n.<\/p>\n

\u0418\u0442\u0430\u043a, DevOps…<\/h2>\n

\n\u2026 \u00e4r ett komplext system som m\u00e5ste inneh\u00e5lla:<\/p>\n