Si Anton Weiss, tagapagtatag at direktor ng Otomato Software, isa sa mga nagpasimula at tagapagturo ng unang sertipikasyon ng DevOps sa Israel, ay nagsalita sa nakaraang taon tungkol sa teorya ng kaguluhan at sa mga pangunahing prinsipyo ng chaos engineering, at ipinaliwanag din kung paano gumagana ang perpektong organisasyon ng DevOps sa hinaharap.
Naghanda kami ng tekstong bersyon ng ulat.
Magandang umaga!
DevOpsDays sa Moscow para sa ikalawang sunod na taon, ito ang aking pangalawang pagkakataon sa yugtong ito, marami sa inyo ang nasa silid na ito sa pangalawang pagkakataon. Ano ang ibig sabihin nito? Nangangahulugan ito na ang kilusang DevOps sa Russia ay lumalaki, dumarami, at higit sa lahat, nangangahulugan ito na dumating na ang oras upang pag-usapan kung ano ang DevOps sa 2018.
Itaas ang iyong mga kamay na nag-iisip na ang DevOps ay isa nang propesyon sa 2018? May mga ganyan. Mayroon bang anumang mga inhinyero ng DevOps sa silid na ang paglalarawan ng trabaho ay nagsasabing "DevOps Engineer"? Mayroon bang anumang mga tagapamahala ng DevOps sa silid? Walang ganoong. Mga arkitekto ng DevOps? Hindi rin. Hindi sapat. Totoo ba talaga na walang nagsasabi na sila ay isang engineer ng DevOps?
Kaya karamihan sa inyo ay nag-iisip na ito ay isang anti-pattern? Na hindi dapat umiral ang ganoong propesyon? Maaari nating isipin ang anumang gusto natin, ngunit habang iniisip natin, ang industriya ay taimtim na sumusulong sa tunog ng trumpeta ng DevOps.
Sino ang nakarinig tungkol sa isang bagong paksa na tinatawag na DevDevOps? Ito ay isang bagong diskarte na nagbibigay-daan para sa epektibong pakikipagtulungan sa pagitan ng mga developer at devops. At hindi na bago. Sa paghusga sa Twitter, nagsimula na silang pag-usapan ito 4 na taon na ang nakakaraan. At hanggang ngayon, lumalaki at lumalaki ang interes dito, ibig sabihin, may problema. Kailangang lutasin ang problema.
Kami ay mga taong malikhain, hindi kami basta-basta nagpapahinga. Sinasabi namin: Ang DevOps ay hindi sapat na komprehensibong salita; kulang pa rin ito ng lahat ng uri ng iba't ibang mga kawili-wiling elemento. At pumunta kami sa aming mga lihim na laboratoryo at nagsimulang gumawa ng mga kawili-wiling mutasyon: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Ang logic ay bakal, tama? Ang aming sistema ng paghahatid ay hindi gumagana, ang aming mga system ay hindi matatag at ang aming mga gumagamit ay hindi nasisiyahan, wala kaming oras upang ilunsad ang software sa oras, hindi kami umaangkop sa badyet. Paano natin lulutasin ang lahat ng ito? Gagawa tayo ng bagong salita! Magtatapos ito sa "Ops" at malulutas ang problema.
Kaya tinawag ko itong diskarte - "Ops, at ang problema ay nalutas na."
Nawawala ang lahat ng ito sa background kung ipaalala natin sa ating sarili kung bakit natin naisip ang lahat ng ito. Nakabuo kami ng buong bagay na ito ng DevOps upang gawing walang harang, walang sakit, mahusay, at higit sa lahat, kasiya-siya hangga't maaari ang paghahatid ng software at ang aming sariling gawain sa prosesong ito.
Lumaki ang DevOps sa sakit. At pagod na tayong maghirap. At para mangyari ang lahat ng ito, umaasa kami sa mga evergreen na kasanayan: epektibong pakikipagtulungan, mga kasanayan sa daloy, at higit sa lahat, pag-iisip ng mga system, dahil kung wala ito walang gumagana ang DevOps.
Ano ang sistema?
At kung pinag-uusapan na natin ang tungkol sa pag-iisip ng mga sistema, paalalahanan natin ang ating sarili kung ano ang isang sistema.
Kung ikaw ay isang rebolusyonaryong hacker, kung gayon para sa iyo ang sistema ay malinaw na masama. Isa itong ulap na bumabalot sa iyo at pinipilit kang gawin ang mga bagay na ayaw mong gawin.
Mula sa pananaw ng mga sistema ng pag-iisip, ang isang sistema ay isang kabuuan na binubuo ng mga bahagi. Sa ganitong kahulugan, ang bawat isa sa atin ay isang sistema. Ang mga organisasyong pinagtatrabahuhan namin ay mga sistema. At ang itinatayo mo at ako ay tinatawag na sistema.
Ang lahat ng ito ay bahagi ng isang malaking socio-technological system. At kung mauunawaan lamang natin kung paano gumagana ang socio-technological system na ito nang sama-sama, saka lang natin mai-optimize ang isang bagay sa bagay na ito.
Mula sa pananaw ng pag-iisip ng mga sistema, ang isang sistema ay may iba't ibang mga kawili-wiling katangian. Una, ito ay binubuo ng mga bahagi, na nangangahulugan na ang pag-uugali nito ay nakasalalay sa pag-uugali ng mga bahagi. Bukod dito, ang lahat ng mga bahagi nito ay magkakaugnay din. Lumalabas na kung mas maraming bahagi ang isang sistema, mas mahirap maunawaan o mahulaan ang pag-uugali nito.
Mula sa pananaw ng pag-uugali, may isa pang kawili-wiling katotohanan. Ang sistema ay maaaring gumawa ng isang bagay na wala sa mga indibidwal na bahagi nito ay maaaring gawin.
Tulad ng sinabi ni Dr. Russell Ackoff (isa sa mga tagapagtatag ng system thinking), ito ay medyo madaling patunayan sa isang eksperimento sa pag-iisip. Halimbawa, sino sa silid ang marunong magsulat ng code? Mayroong maraming mga kamay, at ito ay normal, dahil ito ay isa sa mga pangunahing kinakailangan para sa aming propesyon. Marunong ka bang magsulat, ngunit maaari bang isulat ng iyong mga kamay ang code nang hiwalay sa iyo? May mga taong magsasabi: "Hindi ang mga kamay ko ang sumulat ng code, ang utak ko ang nagsusulat ng code." Maaari bang isulat ng iyong utak ang code nang hiwalay sa iyo? Well, malamang hindi.
Ang utak ay isang kamangha-manghang makina, hindi natin alam ang 10% kung paano ito gumagana doon, ngunit hindi ito maaaring gumana nang hiwalay sa sistema na ating katawan. At ito ay madaling patunayan: buksan ang iyong bungo, ilabas ang iyong utak, ilagay ito sa harap ng computer, hayaan siyang sumulat ng isang bagay na simple. "Hello, world" sa Python, halimbawa.
Kung ang isang sistema ay maaaring gumawa ng isang bagay na wala sa mga bahagi nito ay maaaring gawin nang hiwalay, nangangahulugan ito na ang pag-uugali nito ay hindi tinutukoy ng pag-uugali ng mga bahagi nito. Ano ang tinutukoy nito? Ito ay tinutukoy ng pakikipag-ugnayan sa pagitan ng mga bahaging ito. At ayon dito, mas maraming bahagi ang mayroon, mas kumplikado ang mga pakikipag-ugnayan, mas mahirap maunawaan at mahulaan ang pag-uugali ng system. At ginagawa nitong magulo ang ganitong sistema, dahil anuman, kahit na ang pinaka-hindi gaanong mahalaga, hindi nakikitang pagbabago sa anumang bahagi ng system ay maaaring humantong sa ganap na hindi mahulaan na mga resulta.
Ang pagiging sensitibo sa mga paunang kondisyon ay unang natuklasan at pinag-aralan ng Amerikanong meteorologist na si Ed Lorenz. Kasunod nito, tinawag itong "butterfly effect" at humantong sa pagbuo ng isang kilusan ng siyentipikong pag-iisip na tinatawag na "chaos theory." Ang teoryang ito ay naging isa sa mga pangunahing pagbabago ng paradigma sa agham ng ika-20 siglo.
Teorya ng kaguluhan
Ang mga taong nag-aaral ng kaguluhan ay tinatawag ang kanilang sarili na mga chaosologist.
Sa totoo lang, ang dahilan ng ulat na ito ay, sa pagtatrabaho sa mga kumplikadong distributed system at malalaking internasyonal na organisasyon, sa isang punto ay napagtanto ko na ito ang nararamdaman ko. Ako ay isang chaosologist. Ito ay karaniwang isang matalinong paraan ng pagsasabi: "Hindi ko maintindihan kung ano ang nangyayari dito at hindi ko alam kung ano ang gagawin tungkol dito."
Sa tingin ko, marami din sa inyo ang madalas na nakakaramdam ng ganito, kaya chaosologist din kayo. Inaanyayahan kita sa guild ng mga chaosologist. Ang mga sistemang pag-aaralan mo at ako, mahal na mga chaosologist, ay tinatawag na "complex adaptive system."
Ano ang adaptability? Ang kakayahang umangkop ay nangangahulugan na ang indibidwal at kolektibong pag-uugali ng mga bahagi sa naturang adaptive system ay nagbabago at nag-aayos ng sarili, tumutugon sa mga kaganapan o chain ng mga micro-event sa system. Ibig sabihin, ang sistema ay umaangkop sa mga pagbabago sa pamamagitan ng self-organization. At ang kakayahang ito na mag-organisa ng sarili ay batay sa boluntaryo, ganap na desentralisadong kooperasyon ng mga malayang awtonomous na ahente.
Ang isa pang kawili-wiling pag-aari ng naturang mga sistema ay ang mga ito ay malayang nasusukat. Ano ang dapat na walang alinlangan na interesante sa atin, bilang mga chaosologist-engineer. Kaya, kung sinabi natin na ang pag-uugali ng isang kumplikadong sistema ay tinutukoy ng pakikipag-ugnayan ng mga bahagi nito, kung gayon ano ang dapat nating maging interesado? Pakikipag-ugnayan.
May dalawa pang kawili-wiling natuklasan.
Una, naiintindihan namin na ang isang kumplikadong sistema ay hindi maaaring gawing simple sa pamamagitan ng pagpapasimple ng mga bahagi nito. Pangalawa, ang tanging paraan upang gawing simple ang isang kumplikadong sistema ay sa pamamagitan ng pagpapasimple ng mga pakikipag-ugnayan sa pagitan ng mga bahagi nito.
Paano tayo nakikipag-ugnayan? Ikaw at ako ay lahat ng bahagi ng isang malaking sistema ng impormasyon na tinatawag na lipunan ng tao. Nakikipag-ugnayan tayo sa pamamagitan ng isang karaniwang wika, kung mayroon tayo nito, kung nahanap natin ito.
Ngunit ang wika mismo ay isang kumplikadong sistema ng adaptive. Alinsunod dito, upang makipag-ugnayan nang mas mahusay at simple, kailangan nating lumikha ng ilang uri ng mga protocol. Ibig sabihin, ilang pagkakasunud-sunod ng mga simbolo at aksyon na gagawing mas simple, mas mahuhulaan, mas mauunawaan ang pagpapalitan ng impormasyon sa pagitan natin.
Nais kong sabihin na ang mga uso tungo sa pagiging kumplikado, patungo sa kakayahang umangkop, patungo sa desentralisasyon, patungo sa kaguluhan ay maaaring masubaybayan sa lahat ng bagay. At sa mga sistemang binuo mo at ako, at sa mga sistemang iyon kung saan tayo ay bahagi.
At para hindi maging walang batayan, tingnan natin kung paano nagbabago ang mga system na nilikha natin.
Hinihintay mo ang salitang ito, naiintindihan ko. Kami ay nasa isang kumperensya ng DevOps, ngayon ang salitang ito ay maririnig ng halos isang daang libong beses at pagkatapos ay managinip kami tungkol dito sa gabi.
Ang Microservices ang unang software architecture na lumitaw bilang reaksyon sa mga kasanayan sa DevOps, na idinisenyo upang gawing mas flexible, mas nasusukat, at matiyak ang tuluy-tuloy na paghahatid ng aming mga system. Paano niya ito ginagawa? Sa pamamagitan ng pagbawas sa dami ng mga serbisyo, pagbabawas sa saklaw ng mga problema na pinoproseso ng mga serbisyong ito, pagbabawas ng oras ng paghahatid. Iyon ay, binabawasan at pinapasimple natin ang mga bahagi ng system, pinapataas ang kanilang bilang, at naaayon, ang pagiging kumplikado ng mga pakikipag-ugnayan sa pagitan ng mga bahaging ito ay palaging tumataas, iyon ay, ang mga bagong problema ay lumitaw na kailangan nating lutasin.
Ang mga microservice ay hindi ang katapusan, ang mga microservice ay, sa pangkalahatan, ay kahapon na, dahil ang Serverless ay darating. Nasunog lahat ng server, walang server, walang operating system, puro executable code lang. Ang mga pagsasaayos ay hiwalay, ang mga estado ay hiwalay, ang lahat ay kinokontrol ng mga kaganapan. Kagandahan, kalinisan, katahimikan, walang kaganapan, walang nangyayari, kumpletong kaayusan.
Nasaan ang pagiging kumplikado? Ang hirap, siyempre, sa mga pakikipag-ugnayan. Magkano ang magagawa ng isang function sa sarili nitong? Paano ito nakikipag-ugnayan sa iba pang mga function? Mga pila ng mensahe, mga database, mga tagabalanse. Paano muling likhain ang ilang kaganapan kapag naganap ang isang pagkabigo? Napakaraming tanong at kakaunting sagot.
Ang Microservices at Serverless ang tinatawag naming mga geek hipster na Cloud Native. Ito ay tungkol sa ulap. Ngunit likas din na limitado ang cloud sa scalability nito. Nakasanayan na nating isipin ito bilang isang distributed system. Sa katunayan, saan nakatira ang mga server ng cloud provider? Sa mga data center. Iyon ay, mayroon kaming isang uri ng sentralisadong, napakalimitado, ipinamamahagi na modelo dito.
Ngayon naiintindihan namin na ang Internet of Things ay hindi na lamang malalaking salita na kahit na ayon sa katamtamang mga hula, bilyun-bilyong device na nakakonekta sa Internet ang naghihintay sa atin sa susunod na lima hanggang sampung taon. Isang malaking halaga ng kapaki-pakinabang at walang silbi na data na isasama sa cloud at ia-upload mula sa cloud.
Hindi magtatagal ang cloud, kaya lalo tayong nag-uusap tungkol sa tinatawag na edge computing. O gusto ko rin ang kahanga-hangang kahulugan ng "fog computing". Ito ay nababalot ng mistisismo ng romantikismo at misteryo.
Fog computing. Ang punto ay ang mga ulap ay mga sentralisadong kumpol ng tubig, singaw, yelo, at mga bato. At ang fog ay mga patak ng tubig na nakakalat sa paligid natin sa atmospera.
Sa paradigm ng fog, karamihan sa mga gawain ay ginagawa ng mga droplet na ito nang ganap na autonomously o sa pakikipagtulungan sa iba pang mga droplet. At lumingon lamang sila sa ulap kapag talagang nadiin sila.
Iyon ay, muli ang desentralisasyon, awtonomiya, at, siyempre, naiintindihan na ng marami sa inyo kung saan pupunta ang lahat ng ito, dahil hindi mo maaaring pag-usapan ang tungkol sa desentralisasyon nang hindi binabanggit ang blockchain.
May mga naniniwala, ito ang mga nag-invest sa cryptocurrency. May mga naniniwala ngunit natatakot, tulad ko, halimbawa. At may mga hindi naniniwala. Dito maaari mong tratuhin nang iba. Mayroong teknolohiya, isang bagong hindi kilalang bagay, may mga problema. Tulad ng anumang bagong teknolohiya, itinataas nito ang higit pang mga katanungan kaysa sa mga sagot nito.
Ang hype sa paligid ng blockchain ay naiintindihan. Sa isang tabi, ang teknolohiya mismo ay nagtataglay ng mga kahanga-hangang pangako para sa isang mas maliwanag na hinaharap: higit na kalayaan, higit na awtonomiya, naipamahagi ang pandaigdigang tiwala. Ano ang hindi gusto?
Alinsunod dito, parami nang parami ang mga inhinyero sa buong mundo na nagsisimulang bumuo ng mga desentralisadong aplikasyon. At ito ay isang kapangyarihan na hindi maaaring bale-walain sa pamamagitan lamang ng pagsasabi: "Ahh, ang blockchain ay isang hindi magandang ipinapatupad na distributed database." O gaya ng gustong sabihin ng mga nag-aalinlangan: "Walang tunay na aplikasyon para sa blockchain." Kung iisipin, 150 taon na ang nakalilipas ay sinabi nila ang parehong bagay tungkol sa kuryente. At tama pa nga sila sa ilang mga paraan, dahil ang ginagawang posible ng kuryente ngayon ay hindi posible sa ika-19 na siglo.
Sa pamamagitan ng paraan, sino ang nakakaalam kung anong uri ng logo ang nasa screen? Ito ay Hyperledger. Ito ay isang proyekto na binuo sa ilalim ng tangkilik ng The Linux Foundation at may kasamang hanay ng mga teknolohiyang blockchain. Ito ang tunay na lakas ng aming open source na komunidad.
Chaos Engineering
Kaya, ang sistema na aming binuo ay nagiging mas at mas kumplikado, mas magulo, at mas at mas adaptive. Ang Netflix ay mga pioneer ng mga microservice system. Kabilang sila sa mga unang nakaunawa nito, nakabuo sila ng isang set ng mga tool na tinawag nilang Simian Army, na ang pinakasikat ay . Tinukoy niya kung ano ang naging kilala bilang .
Sa pamamagitan ng paraan, sa proseso ng paggawa sa ulat, isinalin pa namin ang tekstong ito sa Russian, kaya pumunta sa , basahin, puna, pagalitan.
Sa madaling sabi, ang mga prinsipyo ng chaos engineering ay nagsasabi ng mga sumusunod. Ang mga kumplikadong distributed system ay likas na hindi mahuhulaan at likas na buggy. Ang mga error ay hindi maiiwasan, na nangangahulugang kailangan nating tanggapin ang mga error na ito at magtrabaho kasama ang mga system na ito sa isang ganap na naiibang paraan.
Kami mismo ay dapat subukang ipasok ang mga error na ito sa aming mga sistema ng produksyon upang masubukan ang aming mga system para sa parehong kakayahang umangkop, ang mismong kakayahang ito para sa sariling organisasyon, para sa kaligtasan.
At iyon ang nagbabago sa lahat. Hindi lamang kung paano namin ilulunsad ang mga system sa produksyon, kundi pati na rin kung paano namin ito binuo, kung paano namin sinubukan ang mga ito. Walang proseso ng pagpapapanatag o pagyeyelo ng code; sa kabaligtaran, mayroong patuloy na proseso ng destabilisasyon. Sinusubukan naming patayin ang sistema at makita itong patuloy na mabubuhay.
Mga Ibinahagi na System Integration Protocol
Alinsunod dito, kinakailangan nitong magbago ang aming mga system kahit papaano. Upang sila ay maging mas matatag, kailangan nila ng ilang bagong protocol para sa pakikipag-ugnayan sa pagitan ng kanilang mga bahagi. Upang ang mga bahaging ito ay magkasundo at makarating sa isang uri ng sariling organisasyon. At lahat ng uri ng mga bagong tool, lumitaw ang mga bagong protocol, na tinatawag kong "mga protocol para sa pakikipag-ugnayan ng mga distributed system."
Ano ba ang sinasabi ko? Una, ang proyekto . Sinusubukan ng ilan na lumikha ng isang pangkalahatang ipinamamahagi na protocol sa pagsubaybay, na isang ganap na kailangang-kailangan na tool para sa pag-debug ng mga kumplikadong distributed system.
Dagdag pa - . Sinasabi natin na hindi natin mahuhulaan kung ano ang mangyayari sa sistema, ibig sabihin, kailangan nating dagdagan ang observability, observability. Ang opentracing ay kabilang sa isang pamilya ng mga tool na nagbibigay ng obserbasyon sa aming mga system. Ngunit kailangan natin ng pagmamasid upang matukoy kung ang sistema ay kumikilos tulad ng inaasahan natin o hindi. Paano natin tinukoy ang inaasahang pag-uugali? Sa pamamagitan ng pagtukoy ng ilang uri ng patakaran, ilang hanay ng mga panuntunan. Ang proyekto ng Open Policy Agent ay gumagana upang tukuyin ang hanay ng mga panuntunan sa isang spectrum mula sa pag-access sa paglalaan ng mapagkukunan.
Gaya ng sinabi namin, ang aming mga system ay higit na naaakit sa kaganapan. Ang Serverless ay isang magandang halimbawa ng mga system na hinimok ng kaganapan. Upang mailipat namin ang mga kaganapan sa pagitan ng mga system at masubaybayan ang mga ito, kailangan namin ng ilang karaniwang wika, ilang karaniwang protocol para sa kung paano namin pinag-uusapan ang mga kaganapan, kung paano namin ipinapadala ang mga ito sa isa't isa. Ito ang tawag sa isang proyekto .
Ang tuluy-tuloy na daloy ng mga pagbabagong dumadaloy sa aming mga system, na patuloy na nagpapawalang-tatag sa mga ito, ay isang tuluy-tuloy na daloy ng mga artifact ng software. Upang mapanatili natin ang patuloy na daloy ng mga pagbabago na ito, kailangan natin ng ilang uri ng karaniwang protocol kung saan maaari nating pag-usapan kung ano ang artifact ng software, kung paano ito nasubok, kung anong pagpapatunay ang naipasa nito. Ito ang tawag sa isang proyekto . Iyon ay, isang karaniwang metadata protocol para sa mga artifact ng software.
At sa wakas, kung gusto nating maging ganap na independyente, adaptive, at organisado sa sarili ang ating mga system, dapat nating bigyan sila ng karapatan sa pagkilala sa sarili. Tinawag ang proyekto Ganito talaga ang ginagawa niya. Isa rin itong proyekto sa ilalim ng tangkilik ng Cloud Native Computing Foundation.
Ang lahat ng mga proyektong ito ay bata pa, lahat sila ay nangangailangan ng ating pagmamahal, ang ating pagpapatunay. Lahat ito ay open source, ang aming pagsubok, ang aming pagpapatupad. Ipinapakita nila sa amin kung saan patungo ang teknolohiya.
Ngunit ang DevOps ay hindi kailanman naging pangunahing tungkol sa teknolohiya, ito ay palaging tungkol sa pakikipagtulungan sa pagitan ng mga tao. At, nang naaayon, kung gusto nating baguhin ang mga sistemang binuo natin, dapat nating baguhin ang ating sarili. Sa katunayan, nagbabago pa rin tayo; wala tayong masyadong mapagpipilian.
Mayroong isang kahanga-hanga British na manunulat na si Rachel Botsman, kung saan nagsusulat siya tungkol sa ebolusyon ng tiwala sa buong kasaysayan ng tao. Sinabi niya na sa una, sa mga primitive na lipunan, ang tiwala ay lokal, ibig sabihin, pinagkakatiwalaan lamang namin ang mga personal naming kilala.
Pagkatapos ay nagkaroon ng napakahabang panahon - isang madilim na panahon kung kailan ang tiwala ay sentralisado, noong nagsimula tayong magtiwala sa mga taong hindi natin kilala batay sa katotohanan na tayo ay kabilang sa parehong pampublikong institusyon o estado.
At ito ang nakikita natin sa ating makabagong mundo: ang pagtitiwala ay nagiging higit na ipinamamahagi at desentralisado, at ito ay batay sa kalayaan ng mga daloy ng impormasyon, sa pagkakaroon ng impormasyon.
Kung iisipin mo, ang mismong accessibility na ito, na ginagawang posible ang tiwala na ito, ang ipinapatupad mo at ako. Nangangahulugan ito na dapat magbago ang paraan ng ating pakikipagtulungan at ang paraan ng paggawa nito, dahil hindi na gumagana ang mga sentralisadong, hierarchical na organisasyon ng IT noong unang panahon. Nagsisimula silang mamatay.
Mga Pangunahing Kaalaman sa DevOps Organization
Ang perpektong organisasyon ng DevOps sa hinaharap ay isang desentralisado, adaptive na sistema na binubuo ng mga autonomous na team, bawat isa ay binubuo ng mga autonomous na indibidwal. Ang mga pangkat na ito ay nakakalat sa buong mundo, epektibong nakikipagtulungan sa isa't isa gamit ang asynchronous na komunikasyon, gamit ang napakalinaw na mga protocol ng komunikasyon. Napakaganda, hindi ba? Isang napakagandang kinabukasan.
Siyempre, wala sa mga ito ang posible nang walang pagbabago sa kultura. Dapat tayong magkaroon ng transformational leadership, personal na responsibilidad, internal motivation.
Ito ang batayan ng mga organisasyon ng DevOps: transparency ng impormasyon, asynchronous na komunikasyon, transformational leadership, desentralisasyon.
Burnout
Ang mga sistema kung saan bahagi tayo at ang mga binuo natin ay lalong magulo, at mahirap para sa ating mga tao na makayanan ang pag-iisip na ito, mahirap isuko ang ilusyon ng kontrol. Sinisikap naming patuloy na kontrolin ang mga ito, at madalas itong humahantong sa pagka-burnout. Sinasabi ko ito mula sa aking sariling karanasan, nasunog din ako, na-disable din ako sa hindi inaasahang mga pagkabigo sa produksyon.
Ang burnout ay nangyayari kapag sinubukan nating kontrolin ang isang bagay na likas na hindi makontrol. Kapag na-burn out tayo, nawawalan ng kahulugan ang lahat dahil nawawalan tayo ng pagnanais na gumawa ng bago, nagiging defensive tayo at nagsimulang ipagtanggol kung ano ang mayroon tayo.
Ang propesyon ng inhinyero, na madalas kong gustong ipaalala sa aking sarili, ay una at pangunahin sa isang malikhaing propesyon. Kung nawalan tayo ng pagnanais na lumikha ng isang bagay, pagkatapos ay nagiging abo tayo, nagiging abo. Nasusunog ang mga tao, nasusunog ang buong organisasyon.
Sa aking palagay, ang pagtanggap lamang sa malikhaing kapangyarihan ng kaguluhan, ang pagbuo lamang ng pagtutulungan ayon sa mga prinsipyo nito ang tutulong sa atin upang hindi mawala ang maganda sa ating propesyon.
Ito ang nais ko para sa iyo: mahalin ang iyong trabaho, mahalin ang ginagawa namin. Ang mundong ito ay kumakain ng impormasyon, mayroon tayong karangalan na pakainin ito. Kaya't pag-aralan natin ang kaguluhan, maging chaosologist tayo, magdala tayo ng halaga, lumikha ng bago, mabuti, ang mga problema, tulad ng nalaman na natin, ay hindi maiiwasan, at kapag lumitaw, sasabihin lang natin na "Ops!" At ang problema ay nalutas.
Ano maliban sa Chaos Monkey?
Sa katunayan, ang lahat ng mga instrumentong ito ay napakabata. Ang parehong mga tool na binuo ng Netflix para sa kanilang sarili. Bumuo ng iyong sariling mga tool. Basahin ang mga prinsipyo ng chaos engineering at ipamuhay ang mga prinsipyong iyon sa halip na subukang maghanap ng iba pang mga tool na nagawa na ng ibang tao.
Subukang unawain kung paano masira ang iyong mga system at simulan ang pagsira sa mga ito at tingnan kung paano sila mananatili. Ito ang mauna. At maaari kang maghanap ng mga tool. Mayroong lahat ng uri ng mga proyekto.
Hindi ko masyadong naintindihan ang sandaling sinabi mo na ang system ay hindi maaaring pasimplehin sa pamamagitan ng pagpapasimple sa mga bahagi nito, at agad na lumipat sa mga microservice, na nagpapasimple sa system sa pamamagitan ng pagpapasimple ng mga mismong bahagi at pagpapakumplikado ng mga pakikipag-ugnayan. Ang mga ito ay mahalagang dalawang bahagi na sumasalungat sa isa't isa.
Tama, ang mga microservice ay isang napakakontrobersyal na paksa sa pangkalahatan. Sa katunayan, ang pagpapasimple ng mga bahagi ay nagdaragdag ng kakayahang umangkop. Ano ang ibinibigay ng mga microservice? Nagbibigay sila sa amin ng kakayahang umangkop at bilis, ngunit tiyak na hindi sila nagbibigay sa amin ng pagiging simple. Pinapataas nila ang kahirapan.
Kaya, sa pilosopiya ng DevOps, ang mga microservice ay hindi isang magandang bagay?
Anumang kabutihan ay may reverse side. Ang pakinabang nito ay pinapataas nito ang kakayahang umangkop, na nagbibigay-daan sa amin na gumawa ng mga pagbabago nang mas mabilis, ngunit pinapataas nito ang pagiging kumplikado at samakatuwid ay ang hina ng buong system.
Gayunpaman, ano ang higit na diin: sa pagpapasimple ng pakikipag-ugnayan o sa pagpapasimple ng mga bahagi?
Ang diin, siyempre, ay sa pagpapasimple ng mga pakikipag-ugnayan, dahil kung titingnan natin ito mula sa punto ng view kung paano kami nakikipagtulungan sa iyo, kung gayon, una sa lahat, kailangan naming bigyang-pansin ang pagpapasimple ng mga pakikipag-ugnayan, at hindi sa pagpapasimple ng trabaho. ng bawat isa sa atin nang hiwalay. Dahil ang pagpapasimple sa trabaho ay nangangahulugan ng pagiging robot. Dito sa McDonald's ito ay gumagana nang normal kapag mayroon kang mga tagubilin: dito mo ilagay ang burger, dito mo ibuhos ang sauce dito. Hindi ito gumagana sa aming malikhaing gawain.
Totoo ba na lahat ng sinabi mo ay nabubuhay sa mundong walang kompetisyon, at ang kaguluhan doon ay napakabait, at walang mga kontradiksyon sa loob ng kaguluhang ito, walang gustong kumain o pumatay ng sinuman? Paano dapat ang kumpetisyon at DevOps?
Well, depende ito sa kung anong uri ng kompetisyon ang pinag-uusapan natin. Tungkol ba ito sa kompetisyon sa lugar ng trabaho o kompetisyon sa pagitan ng mga kumpanya?
Tungkol sa kompetisyon ng mga serbisyong umiiral dahil ang mga serbisyo ay hindi ilang kumpanya. Lumilikha kami ng bagong uri ng kapaligiran ng impormasyon, at hindi mabubuhay ang anumang kapaligiran nang walang kumpetisyon. May kompetisyon sa lahat ng dako.
Ang parehong Netflix, itinuturing namin silang isang huwaran. Bakit nila ito naisip? Dahil kailangan nilang maging mapagkumpitensya. Ang kakayahang umangkop at bilis ng paggalaw na ito ay tiyak na pinaka mapagkumpitensyang kinakailangan; ito ay nagpapakilala ng kaguluhan sa aming mga system. Ibig sabihin, ang kaguluhan ay hindi isang bagay na sinasadya nating gawin dahil gusto natin ito, ito ay isang bagay na nangyayari dahil hinihingi ito ng mundo. Kailangan lang nating mag-adapt. At kaguluhan, ito ay tiyak na resulta ng kumpetisyon.
Nangangahulugan ba ito na ang kaguluhan ay ang kawalan ng mga layunin, kumbaga? O iyong mga layunin na hindi natin gustong makita? Nasa bahay kami at hindi naiintindihan ang mga layunin ng iba. Ang kumpetisyon, sa katunayan, ay dahil sa katotohanan na mayroon tayong malinaw na mga layunin at alam natin kung saan tayo hahantong sa bawat susunod na sandali sa oras. Ito, mula sa aking pananaw, ay ang kakanyahan ng DevOps.
Tingnan din ang tanong. Sa tingin ko lahat tayo ay may parehong layunin: upang mabuhay at gawin ito
pinakamalaking kasiyahan. At ang mapagkumpitensyang layunin ng anumang organisasyon ay pareho. Madalas na nangyayari ang kaligtasan sa pamamagitan ng kumpetisyon, wala kang magagawa tungkol dito.
Kumperensya ngayong taon magaganap sa Disyembre 7 sa Technopolis. Tumatanggap kami ng mga aplikasyon para sa mga ulat hanggang Nobyembre 11. sa amin kung gusto mong magsalita.
Ang pagpaparehistro para sa mga kalahok ay bukas, ang mga tiket ay nagkakahalaga ng 7000 rubles. Sumali ka!
Pinagmulan: www.habr.com