Anton Weiss, pengasas dan pengarah Perisian Otomato, salah seorang pemula dan pengajar pensijilan DevOps pertama di Israel, bercakap pada tahun lepas tentang teori huru-hara dan prinsip utama kejuruteraan huru-hara, dan juga menerangkan cara organisasi DevOps yang ideal pada masa hadapan berfungsi.
Kami telah menyediakan versi teks laporan.
Good morning!
DevOpsDays di Moscow untuk tahun kedua berturut-turut, ini kali kedua saya di pentas ini, ramai di antara anda berada di bilik ini untuk kali kedua. Apakah maksudnya? Ini bermakna pergerakan DevOps di Rusia semakin berkembang, membiak, dan yang paling penting, ini bermakna sudah tiba masanya untuk bercakap tentang apa itu DevOps pada 2018.
Angkat tangan anda yang berpendapat bahawa DevOps sudah menjadi profesion pada tahun 2018? Ada yang begitu. Adakah terdapat jurutera DevOps di dalam bilik yang keterangan tugasnya tertera "Jurutera DevOps"? Adakah terdapat mana-mana pengurus DevOps di dalam bilik? Tidak ada seperti itu. Arkitek DevOps? Juga tidak. Tidak cukup. Adakah benar bahawa tiada siapa yang mengatakan mereka seorang jurutera DevOps?
Jadi kebanyakan anda fikir ini adalah anti-corak? Bahawa profesion seperti itu tidak sepatutnya wujud? Kita boleh berfikir apa sahaja yang kita mahu, tetapi semasa kita berfikir, industri dengan sungguh-sungguh bergerak ke hadapan untuk mendengar bunyi sangkakala DevOps.
Siapa yang pernah mendengar tentang topik baharu yang dipanggil DevDevOps? Ini adalah teknik baharu yang membolehkan kerjasama berkesan antara pembangun dan devops. Dan tidak begitu baru. Berdasarkan Twitter, mereka sudah mula bercakap tentang ini 4 tahun lalu. Dan sehingga kini, minat dalam hal ini semakin meningkat dan berkembang, iaitu, ada masalah. Masalah itu perlu diselesaikan.
Kami adalah orang yang kreatif, kami tidak hanya berehat. Kami berkata: DevOps bukanlah perkataan yang cukup komprehensif; ia masih kekurangan pelbagai jenis elemen menarik yang berbeza. Dan kami pergi ke makmal rahsia kami dan mula menghasilkan mutasi yang menarik: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logiknya kuku besi, kan? Sistem penghantaran kami tidak berfungsi, sistem kami tidak stabil dan pengguna kami tidak berpuas hati, kami tidak mempunyai masa untuk melancarkan perisian tepat pada masanya, kami tidak sesuai dengan bajet. Bagaimana kita hendak menyelesaikan semua ini? Kami akan menghasilkan perkataan baru! Ia akan berakhir dengan "Ops" dan masalah itu diselesaikan.
Jadi saya memanggil pendekatan ini - "Ops, dan masalah itu diselesaikan."
Ini semua memudar ke latar belakang jika kita mengingatkan diri kita sendiri mengapa kita datang dengan semua ini. Kami menghasilkan keseluruhan perkara DevOps ini untuk menjadikan penghantaran perisian dan kerja kami sendiri dalam proses ini sebagai tanpa halangan, tidak menyakitkan, cekap, dan yang paling penting, menyeronokkan yang mungkin.
DevOps berkembang daripada kesakitan. Dan kita sudah bosan dengan penderitaan. Dan untuk semua ini berlaku, kami bergantung pada amalan malar hijau: kerjasama yang berkesan, amalan aliran, dan yang paling penting, pemikiran sistem, kerana tanpanya tiada DevOps berfungsi.
Apakah sistemnya?
Dan jika kita sudah bercakap tentang pemikiran sistem, mari kita ingatkan diri kita apa itu sistem.
Jika anda seorang penggodam revolusioner, maka bagi anda sistem itu jelas jahat. Ia adalah awan yang menggantung di atas anda dan memaksa anda melakukan perkara yang anda tidak mahu lakukan.
Dari sudut pemikiran sistem, sistem ialah keseluruhan yang terdiri daripada bahagian-bahagian. Dalam pengertian ini, setiap daripada kita adalah satu sistem. Organisasi tempat kami bekerja adalah sistem. Dan apa yang anda dan saya sedang bina dipanggil sistem.
Semua ini adalah sebahagian daripada satu sistem sosio-teknologi yang besar. Dan hanya jika kita memahami bagaimana sistem sosio-teknologi ini berfungsi bersama, barulah kita dapat benar-benar mengoptimumkan sesuatu dalam perkara ini.
Dari perspektif pemikiran sistem, sistem mempunyai pelbagai sifat yang menarik. Pertama, ia terdiri daripada bahagian, yang bermaksud bahawa tingkah lakunya bergantung pada tingkah laku bahagian. Selain itu, semua bahagiannya juga saling bergantung. Ternyata semakin banyak bahagian sistem, semakin sukar untuk memahami atau meramalkan kelakuannya.
Dari sudut tingkah laku, terdapat satu lagi fakta menarik. Sistem boleh melakukan sesuatu yang tidak boleh dilakukan oleh bahagian individunya.
Seperti kata Dr Russell Ackoff (salah seorang pengasas pemikiran sistem), ini agak mudah untuk dibuktikan dengan eksperimen pemikiran. Sebagai contoh, siapa di dalam bilik itu tahu cara menulis kod? Terdapat banyak tangan, dan ini adalah perkara biasa, kerana ini adalah salah satu keperluan utama untuk profesion kami. Adakah anda tahu cara menulis, tetapi bolehkah tangan anda menulis kod secara berasingan daripada anda? Ada orang yang akan berkata: "Bukan tangan saya yang menulis kod, tetapi otak saya yang menulis kod." Bolehkah otak anda menulis kod secara berasingan daripada anda? Mungkin tidak.
Otak adalah mesin yang menakjubkan, kita tidak tahu 10% cara ia berfungsi di sana, tetapi ia tidak boleh berfungsi secara berasingan daripada sistem badan kita. Dan ini mudah dibuktikan: buka tengkorak anda, keluarkan otak anda, letakkannya di hadapan komputer, biarkan dia cuba menulis sesuatu yang mudah. "Hello, dunia" dalam Python, sebagai contoh.
Jika sistem boleh melakukan sesuatu yang tidak boleh dilakukan oleh mana-mana bahagiannya secara berasingan, maka ini bermakna kelakuannya tidak ditentukan oleh kelakuan bahagiannya. Kemudian ia ditentukan oleh apa? Ia ditentukan oleh interaksi antara bahagian-bahagian ini. Dan dengan itu, lebih banyak bahagian, lebih kompleks interaksi, lebih sukar untuk memahami dan meramalkan tingkah laku sistem. Dan ini menjadikan sistem sedemikian huru-hara, kerana apa-apa, walaupun yang paling tidak penting, perubahan yang tidak dapat dilihat di mana-mana bahagian sistem boleh membawa kepada keputusan yang tidak dapat diramalkan sepenuhnya.
Kepekaan terhadap keadaan awal ini pertama kali ditemui dan dikaji oleh ahli meteorologi Amerika Ed Lorenz. Selepas itu, ia dipanggil "kesan rama-rama" dan membawa kepada perkembangan pergerakan pemikiran saintifik yang dipanggil "teori huru-hara." Teori ini menjadi salah satu anjakan paradigma utama dalam sains abad ke-20.
Teori huru-hara
Orang yang mengkaji huru-hara memanggil diri mereka ahli chaosologist.
Sebenarnya, sebab laporan ini ialah, bekerja dengan sistem pengedaran yang kompleks dan organisasi antarabangsa yang besar, pada satu ketika saya menyedari bahawa ini adalah orang yang saya rasa. Saya seorang ahli chaosologist. Ini pada dasarnya adalah cara bijak untuk mengatakan: "Saya tidak faham apa yang berlaku di sini dan saya tidak tahu apa yang perlu dilakukan mengenainya."
Saya berpendapat bahawa ramai di antara anda juga sering merasa seperti ini, jadi anda juga ahli chaosologist. Saya menjemput anda ke persatuan ahli chaosologist. Sistem yang anda dan saya, rakan ahli chaosologist yang dihormati, akan belajar dipanggil "sistem penyesuaian kompleks."
Apakah kebolehsuaian? Kebolehsuaian bermaksud bahawa tingkah laku individu dan kolektif bahagian dalam sistem penyesuaian sedemikian berubah dan mengatur diri, bertindak balas kepada peristiwa atau rantaian peristiwa mikro dalam sistem. Iaitu, sistem menyesuaikan diri dengan perubahan melalui organisasi diri. Dan keupayaan untuk mengatur diri ini adalah berdasarkan kerjasama sukarela dan terdesentralisasi sepenuhnya oleh ejen autonomi bebas.
Satu lagi sifat menarik bagi sistem sedemikian ialah ia boleh berskala secara bebas. Apa yang pasti menarik minat kita, sebagai ahli chaosologists-engineers. Jadi, jika kita mengatakan bahawa tingkah laku sistem yang kompleks ditentukan oleh interaksi bahagian-bahagiannya, maka apakah yang perlu kita minati? Interaksi.
Terdapat dua lagi penemuan menarik.
Pertama, kita faham bahawa sistem yang kompleks tidak boleh dipermudahkan dengan memudahkan bahagian-bahagiannya. Kedua, satu-satunya cara untuk memudahkan sistem yang kompleks adalah dengan memudahkan interaksi antara bahagian-bahagiannya.
Bagaimana kita berinteraksi? Anda dan saya adalah sebahagian daripada sistem maklumat besar yang dipanggil masyarakat manusia. Kita berinteraksi melalui bahasa yang sama, jika kita memilikinya, jika kita menjumpainya.
Tetapi bahasa itu sendiri adalah sistem penyesuaian yang kompleks. Sehubungan itu, untuk berinteraksi dengan lebih cekap dan ringkas, kita perlu mencipta beberapa jenis protokol. Iaitu, beberapa urutan simbol dan tindakan yang akan menjadikan pertukaran maklumat antara kita lebih mudah, lebih mudah diramal, lebih mudah difahami.
Saya ingin mengatakan bahawa trend ke arah kerumitan, ke arah penyesuaian, ke arah desentralisasi, ke arah huru-hara boleh dikesan dalam segala-galanya. Dan dalam sistem yang anda dan saya sedang bina, dan dalam sistem yang mana kita adalah sebahagian daripadanya.
Dan bukannya tidak berasas, mari kita lihat bagaimana sistem yang kita cipta berubah.
Anda sedang menunggu perkataan ini, saya faham. Kami berada di persidangan DevOps, hari ini perkataan ini akan didengari kira-kira seratus ribu kali dan kemudian kami akan bermimpi tentangnya pada waktu malam.
Microservices ialah seni bina perisian pertama yang muncul sebagai tindak balas kepada amalan DevOps, yang direka untuk menjadikan sistem kami lebih fleksibel, lebih berskala dan memastikan penghantaran berterusan. Bagaimana dia melakukan ini? Dengan mengurangkan jumlah perkhidmatan, mengurangkan skop masalah yang diproses oleh perkhidmatan ini, mengurangkan masa penghantaran. Iaitu, kita mengurangkan dan memudahkan bahagian sistem, menambah bilangannya, dan dengan itu, kerumitan interaksi antara bahagian ini sentiasa meningkat, iaitu, masalah baru timbul yang perlu kita selesaikan.
Microservices bukanlah penamat, microservices, secara amnya, sudah semalam, kerana Serverless akan datang. Semua pelayan hangus, tiada pelayan, tiada sistem pengendalian, hanya kod boleh laku tulen. Konfigurasi adalah berasingan, keadaan adalah berasingan, semuanya dikawal oleh peristiwa. Kecantikan, kebersihan, kesunyian, tiada peristiwa, tiada apa yang berlaku, perintah lengkap.
Di manakah kerumitannya? Kesukaran, tentu saja, adalah dalam interaksi. Berapa banyak yang boleh dilakukan oleh satu fungsi dengan sendirinya? Bagaimanakah ia berinteraksi dengan fungsi lain? Barisan mesej, pangkalan data, pengimbang. Bagaimana untuk mencipta semula beberapa peristiwa apabila kegagalan berlaku? Banyak soalan dan sedikit jawapan.
Microservices dan Serverless ialah apa yang kami panggil hipster geek Cloud Native. Ini semua tentang awan. Tetapi awan juga sememangnya terhad dalam skalabilitinya. Kami sudah biasa memikirkannya sebagai sistem teragih. Sebenarnya, di manakah pelayan penyedia awan tinggal? Di pusat data. Iaitu, kami mempunyai sejenis model terpusat, sangat terhad, diedarkan di sini.
Hari ini kita faham bahawa Internet of Things bukan lagi sekadar perkataan besar yang walaupun mengikut ramalan sederhana, berbilion-bilion peranti yang disambungkan ke Internet menanti kita dalam tempoh lima hingga sepuluh tahun akan datang. Sejumlah besar data berguna dan tidak berguna yang akan digabungkan ke dalam awan dan dimuat naik dari awan.
Awan tidak akan kekal, jadi kami semakin bercakap tentang sesuatu yang dipanggil pengkomputeran tepi. Atau saya juga suka definisi indah "pengkomputeran kabus". Ia diselubungi mistisisme romantisme dan misteri.
Pengkomputeran kabus. Intinya ialah awan adalah gumpalan air, wap, ais dan batu yang terpusat. Dan kabus adalah titisan air yang bertaburan di sekeliling kita di atmosfera.
Dalam paradigma kabus, kebanyakan kerja dilakukan oleh titisan ini sepenuhnya secara autonomi atau dengan kerjasama titisan lain. Dan mereka beralih ke awan hanya apabila mereka benar-benar tertekan.
Iaitu, sekali lagi desentralisasi, autonomi, dan, sudah tentu, ramai daripada anda sudah memahami ke mana semua ini pergi, kerana anda tidak boleh bercakap tentang desentralisasi tanpa menyebut blockchain.
Ada yang percaya, ini adalah mereka yang telah melabur dalam mata wang kripto. Ada yang percaya tapi takut, macam saya contohnya. Dan ada juga yang tidak percaya. Di sini anda boleh merawat secara berbeza. Ada teknologi, perkara baru yang tidak diketahui, ada masalah. Seperti mana-mana teknologi baru, ia menimbulkan lebih banyak soalan daripada jawapannya.
Gembar-gembur di sekitar blockchain boleh difahami. Mengetepikan tergesa-gesa emas, teknologi itu sendiri memegang janji yang luar biasa untuk masa depan yang lebih cerah: lebih banyak kebebasan, lebih autonomi, kepercayaan global yang diagihkan. Apa yang tidak mahu?
Sehubungan itu, semakin ramai jurutera di seluruh dunia mula membangunkan aplikasi terdesentralisasi. Dan ini adalah kuasa yang tidak boleh diketepikan dengan hanya berkata: "Ahh, blockchain hanyalah pangkalan data teragih yang tidak dilaksanakan dengan baik." Atau seperti yang dikatakan oleh orang yang ragu-ragu: "Tiada aplikasi sebenar untuk blockchain." Jika difikirkan, 150 tahun dahulu mereka mengatakan perkara yang sama tentang elektrik. Dan mereka juga betul dalam beberapa cara, kerana apa yang dimungkinkan oleh elektrik hari ini tidak mungkin berlaku pada abad ke-19.
By the way, siapa tahu jenis logo apa yang ada pada skrin? Ini adalah Hyperledger. Ini adalah projek yang sedang dibangunkan di bawah naungan The Linux Foundation dan termasuk satu set teknologi blockchain. Ini benar-benar kekuatan komuniti sumber terbuka kami.
Kejuruteraan huru-hara
Jadi, sistem yang kita bangunkan menjadi semakin kompleks, semakin huru-hara, dan semakin adaptif. Netflix adalah perintis sistem perkhidmatan mikro. Mereka adalah antara yang pertama memahami perkara ini, mereka membangunkan satu set alat yang mereka namakan Tentera Simian, yang paling terkenal adalah . Dia mentakrifkan apa yang dikenali sebagai .
Ngomong-ngomong, dalam proses mengusahakan laporan itu, kami juga menterjemah teks ini ke dalam bahasa Rusia, jadi pergi ke , baca, komen, tegur.
Secara ringkas, prinsip kejuruteraan huru-hara menyatakan perkara berikut. Sistem teragih yang kompleks sememangnya tidak dapat diramalkan dan sememangnya mempunyai bug. Ralat tidak dapat dielakkan, yang bermaksud kita perlu menerima ralat ini dan bekerja dengan sistem ini dengan cara yang sama sekali berbeza.
Kami sendiri mesti cuba memperkenalkan ralat ini ke dalam sistem pengeluaran kami untuk menguji sistem kami untuk kebolehsuaian yang sama ini, keupayaan untuk organisasi diri, untuk terus hidup.
Dan itu mengubah segala-galanya. Bukan sahaja cara kami melancarkan sistem ke dalam pengeluaran, tetapi juga cara kami membangunkannya, cara kami mengujinya. Tiada proses penstabilan atau pembekuan kod; sebaliknya, terdapat proses ketidakstabilan yang berterusan. Kami cuba untuk membunuh sistem dan melihatnya terus bertahan.
Protokol Integrasi Sistem Teragih
Sehubungan itu, ini memerlukan sistem kami untuk berubah entah bagaimana. Agar mereka menjadi lebih stabil, mereka memerlukan beberapa protokol baharu untuk interaksi antara bahagian mereka. Supaya bahagian-bahagian ini boleh bersetuju dan datang kepada beberapa jenis organisasi diri. Dan semua jenis alat baharu, protokol baharu timbul, yang saya panggil "protokol untuk interaksi sistem teragih."
Apa yang saya cakapkan? Pertama, projek . Sesetengah cuba mencipta protokol pengesanan teragih umum, yang merupakan alat yang sangat diperlukan untuk menyahpepijat sistem teragih yang kompleks.
Selanjutnya - . Kami mengatakan bahawa kami tidak boleh meramalkan apa yang akan berlaku kepada sistem, iaitu, kami perlu meningkatkan kebolehmerhatiannya, kebolehmerhatiannya. Opentracing tergolong dalam keluarga alat yang memberikan pemerhatian kepada sistem kami. Tetapi kita memerlukan pemerhatian untuk menentukan sama ada sistem berkelakuan seperti yang kita harapkan atau tidak. Bagaimanakah kita menentukan tingkah laku yang diharapkan? Dengan mentakrifkan beberapa jenis dasar, beberapa set peraturan. Projek Agen Dasar Terbuka sedang berusaha untuk menentukan set peraturan ini merentas spektrum daripada akses kepada peruntukan sumber.
Seperti yang kami katakan, sistem kami semakin didorong oleh peristiwa. Tanpa pelayan ialah contoh hebat sistem dipacu peristiwa. Untuk membolehkan kami memindahkan acara antara sistem dan menjejakinya, kami memerlukan beberapa bahasa biasa, beberapa protokol biasa untuk cara kami bercakap tentang acara, cara kami menghantarnya kepada satu sama lain. Inilah yang dinamakan projek .
Aliran perubahan berterusan yang membanjiri sistem kami, sentiasa menggugat kestabilannya, ialah aliran artifak perisian yang berterusan. Untuk kita mengekalkan aliran perubahan yang berterusan ini, kita memerlukan beberapa jenis protokol biasa yang melaluinya kita boleh bercakap tentang artifak perisian, cara ia diuji, pengesahan yang telah diluluskan. Inilah yang dinamakan projek . Iaitu, protokol metadata biasa untuk artifak perisian.
Dan akhirnya, jika kita mahu sistem kita benar-benar bebas, adaptif, dan teratur sendiri, kita mesti memberi mereka hak untuk mengenal pasti diri. Projek dipanggil Ini betul-betul apa yang dia lakukan. Ini juga merupakan projek di bawah naungan Cloud Native Computing Foundation.
Semua projek ini masih muda, semuanya memerlukan kasih sayang kami, pengesahan kami. Ini semua sumber terbuka, ujian kami, pelaksanaan kami. Mereka menunjukkan kepada kita ke mana arah tuju teknologi.
Tetapi DevOps tidak pernah terutamanya mengenai teknologi, ia sentiasa mengenai kerjasama antara orang ramai. Dan, sewajarnya, jika kita mahu sistem yang kita bangunkan berubah, maka kita sendiri mesti berubah. Malah, kami sentiasa berubah; kami tidak mempunyai banyak pilihan.
Ada yang indah Penulis British Rachel Botsman, di mana dia menulis tentang evolusi kepercayaan sepanjang sejarah manusia. Dia mengatakan bahawa pada mulanya, dalam masyarakat primitif, kepercayaan adalah setempat, iaitu, kami hanya mempercayai mereka yang kami kenali secara peribadi.
Kemudian terdapat satu tempoh yang sangat panjang - masa gelap apabila kepercayaan dipusatkan, apabila kita mula mempercayai orang yang kita tidak kenali atas dasar fakta bahawa kita tergolong dalam institusi awam atau negeri yang sama.
Dan inilah yang kita lihat dalam dunia moden kita: kepercayaan semakin teragih dan terdesentralisasi, dan ia berdasarkan kebebasan aliran maklumat, pada ketersediaan maklumat.
Jika anda memikirkannya, kebolehcapaian ini, yang menjadikan kepercayaan ini mungkin, adalah perkara yang anda dan saya laksanakan. Ini bermakna bahawa kedua-dua cara kita bekerjasama dan cara kita melakukannya mesti berubah, kerana organisasi IT berhierarki berpusat pada zaman dahulu tidak lagi berfungsi. Mereka mula mati.
Asas Organisasi DevOps
Organisasi DevOps yang ideal pada masa hadapan ialah sistem penyesuaian terpencar yang terdiri daripada pasukan autonomi, masing-masing terdiri daripada individu autonomi. Pasukan ini tersebar di seluruh dunia, bekerjasama secara berkesan antara satu sama lain menggunakan komunikasi tak segerak, menggunakan protokol komunikasi yang sangat telus. Sangat cantik, bukan? Masa depan yang sangat indah.
Sudah tentu, semua ini tidak mungkin tanpa perubahan budaya. Kita mesti mempunyai kepimpinan transformasi, tanggungjawab peribadi, motivasi dalaman.
Ini adalah asas organisasi DevOps: ketelusan maklumat, komunikasi tak segerak, kepimpinan transformasi, desentralisasi.
Burnout
Sistem yang kita ada dan yang kita bina semakin huru-hara, dan sukar bagi kita manusia untuk mengatasi pemikiran ini, sukar untuk melepaskan ilusi kawalan. Kami cuba untuk terus mengawal mereka, dan ini sering menyebabkan keletihan. Saya mengatakan ini dari pengalaman saya sendiri, saya juga terbakar, saya juga dilumpuhkan oleh kegagalan yang tidak diduga dalam pengeluaran.
Burnout berlaku apabila kita cuba mengawal sesuatu yang sememangnya tidak boleh dikawal. Apabila kita terbakar, segala-galanya hilang maknanya kerana kita kehilangan keinginan untuk melakukan sesuatu yang baru, kita menjadi defensif dan mula mempertahankan apa yang kita ada.
Profesion kejuruteraan, seperti yang sering saya ingatkan kepada diri saya sendiri, pertama sekali adalah profesion kreatif. Jika kita hilang keinginan untuk mencipta sesuatu, maka kita bertukar menjadi abu, bertukar menjadi abu. Orang terbakar, seluruh organisasi terbakar.
Pada pendapat saya, hanya menerima kuasa kreatif huru-hara, hanya membina kerjasama mengikut prinsipnya yang akan membantu kita untuk tidak kehilangan apa yang baik dalam profesion kita.
Inilah yang saya harapkan untuk anda: untuk mencintai pekerjaan anda, untuk mencintai apa yang kami lakukan. Dunia ini memakan maklumat, kita mempunyai penghormatan untuk memberinya. Oleh itu, mari kita mengkaji huru-hara, mari menjadi ahli chaosologist, mari kita membawa nilai, mencipta sesuatu yang baru, baik, masalah, seperti yang telah kita ketahui, tidak dapat dielakkan, dan apabila ia muncul, kita hanya akan berkata "Ops!" Dan masalah itu diselesaikan.
Apa selain Chaos Monkey?
Malah, semua instrumen ini sangat muda. Alat binaan Netflix yang sama untuk diri mereka sendiri. Bina alat anda sendiri. Baca prinsip kejuruteraan huru-hara dan hayati prinsip tersebut daripada cuba mencari alatan lain yang telah dibina oleh orang lain.
Cuba fahami bagaimana sistem anda rosak dan mula memecahkannya dan lihat bagaimana ia bertahan. Ini didahulukan. Dan anda boleh mencari alat. Macam-macam projek ada.
Saya tidak begitu memahami saat anda mengatakan bahawa sistem tidak boleh dipermudahkan dengan memudahkan komponennya, dan terus beralih kepada perkhidmatan mikro, yang memudahkan sistem dengan memudahkan komponen itu sendiri dan merumitkan interaksi. Ini pada dasarnya adalah dua bahagian yang bercanggah antara satu sama lain.
Betul, perkhidmatan mikro ialah topik yang sangat kontroversi secara umum. Malah, memudahkan bahagian meningkatkan fleksibiliti. Apakah yang disediakan oleh perkhidmatan mikro? Mereka memberi kita fleksibiliti dan kelajuan, tetapi mereka pastinya tidak memberi kita kesederhanaan. Mereka meningkatkan kesukaran.
Jadi, dalam falsafah DevOps, perkhidmatan mikro bukanlah perkara yang baik?
Mana-mana kebaikan mempunyai sisi terbalik. Faedahnya ialah ia meningkatkan fleksibiliti, membolehkan kita membuat perubahan dengan lebih pantas, tetapi ia meningkatkan kerumitan dan oleh itu kerapuhan keseluruhan sistem.
Namun, apakah yang lebih ditekankan: pada memudahkan interaksi atau pada memudahkan bahagian?
Penekanan, tentu saja, adalah pada memudahkan interaksi, kerana jika kita melihat ini dari sudut cara kami bekerja dengan anda, maka, pertama sekali, kita perlu memberi perhatian kepada memudahkan interaksi, dan bukan pada memudahkan kerja. setiap daripada kita secara berasingan. Kerana memudahkan kerja bermakna bertukar menjadi robot. Di McDonald's ia berfungsi seperti biasa apabila anda mempunyai arahan: di sini anda meletakkan burger, di sini anda tuangkan sos di atasnya. Ini tidak berfungsi sama sekali dalam kerja kreatif kami.
Adakah benar semua yang anda katakan hidup dalam dunia tanpa persaingan, dan huru-hara di sana sangat baik, dan tiada percanggahan dalam kekacauan ini, tiada siapa yang mahu makan atau membunuh sesiapa? Bagaimanakah persaingan dan DevOps sepatutnya berlaku?
Nah, ia bergantung kepada jenis persaingan yang kita bincangkan. Adakah ia mengenai persaingan di tempat kerja atau persaingan antara syarikat?
Mengenai persaingan perkhidmatan yang wujud kerana perkhidmatan bukan beberapa syarikat. Kami sedang mencipta jenis persekitaran maklumat baharu, dan mana-mana persekitaran tidak boleh hidup tanpa persaingan. Terdapat persaingan di mana-mana.
Netflix yang sama, kami mengambil mereka sebagai model peranan. Mengapa mereka datang dengan ini? Kerana mereka perlu berdaya saing. Fleksibiliti dan kelajuan pergerakan ini adalah keperluan yang sangat kompetitif; ia memperkenalkan huru-hara ke dalam sistem kami. Maksudnya, huru-hara bukanlah sesuatu yang kita lakukan secara sedar kerana kita mahu, ia adalah sesuatu yang berlaku kerana dunia menuntutnya. Kita hanya perlu menyesuaikan diri. Dan huru-hara, ia adalah hasil daripada persaingan.
Adakah ini bermakna huru-hara adalah ketiadaan matlamat, seolah-olah? Atau matlamat yang kita tidak mahu lihat? Kami berada di dalam rumah dan tidak memahami matlamat orang lain. Persaingan, sebenarnya, adalah disebabkan oleh fakta bahawa kita mempunyai matlamat yang jelas dan kita tahu di mana kita akan berakhir pada setiap saat berikutnya. Ini, dari sudut pandangan saya, adalah intipati DevOps.
Juga melihat soalan. Saya fikir kita semua mempunyai matlamat yang sama: untuk terus hidup dan melakukannya
kesenangan terbesar. Dan matlamat persaingan mana-mana organisasi adalah sama. Kelangsungan hidup selalunya berlaku melalui persaingan, tiada apa yang boleh anda lakukan mengenainya.
Persidangan tahun ini akan berlangsung pada 7 Disember di Technopolis. Kami menerima permohonan untuk laporan sehingga 11 November. kami jika anda ingin bercakap.
Pendaftaran untuk peserta dibuka, tiket berharga 7000 rubel. Sertai kami!
Sumber: www.habr.com