Anton Weiss, pangadeg lan direktur Otomato Software, salah sawijining inisiator lan instruktur sertifikasi DevOps pisanan ing Israel, ngandika ing taun kepungkur. babagan teori kekacauan lan prinsip utama teknik kekacauan, lan uga nerangake cara kerja organisasi DevOps sing cocog ing mangsa ngarep.
Kita wis nyiapake versi teks laporan.
Good morning
DevOpsDays ing Moskow kanggo taun kaping pindho berturut-turut, iki kaping pindho ing panggung iki, akeh sampeyan ing kamar iki kanggo kaping pindho. Iki artine apa? Iki tegese gerakan DevOps ing Rusia saya tambah akeh, tambah akeh, lan sing paling penting, tegese wektune kanggo ngomong babagan apa DevOps ing 2018.
Angkat tangan sing mikir yen DevOps wis dadi profesi ing 2018? Ana kuwi. Apa ana insinyur DevOps ing ruangan sing deskripsi proyek kasebut "Insinyur DevOps"? Apa ana manajer DevOps ing ruangan kasebut? Ora ana sing kaya ngono. Arsitek DevOps? Uga ora. Ora cukup. Apa pancene ora ana sing ujar manawa dheweke dadi insinyur DevOps?
Dadi umume sampeyan mikir iki minangka anti-pola? Apa profesi kasebut ora kudu ana? Kita bisa mikir apa wae sing dikarepake, nanging nalika kita mikir, industri kasebut terus maju menyang swara trompet DevOps.
Sapa sing wis krungu babagan topik anyar sing diarani DevDevOps? Iki minangka teknik anyar sing ngidini kolaborasi efektif antarane pangembang lan devops. Lan ora dadi anyar. Miturut Twitter, dheweke wis wiwit ngomong babagan iki 4 taun kepungkur. Lan nganti saiki, minat babagan iki saya tambah akeh, yaiku, ana masalah. Masalah kudu dirampungake.
Kita wong kreatif, kita ora mung ngaso. Kita ujar: DevOps dudu tembung sing cukup lengkap; isih ora ana macem-macem unsur sing menarik. Lan kita menyang laboratorium rahasia lan wiwit ngasilake mutasi sing menarik: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logika iku wesi, bener? Sistem pangiriman kita ora fungsional, sistem kita ora stabil lan pangguna ora marem, kita ora duwe wektu kanggo muter piranti lunak kanthi tepat, ora cocog karo anggaran. Kepiye carane kita bakal ngrampungake kabeh iki? Kita bakal nggawe tembung anyar! Iku bakal mungkasi karo "Ops" lan masalah wis ditanggulangi.
Dadi aku nelpon pendekatan iki - "Ops, lan masalah wis ditanggulangi."
Iki kabeh fades menyang latar mburi yen kita ngelingake dhéwé kok kita teka munggah karo kabeh iki. Kita nggawe kabeh bab DevOps iki kanggo nggawe pangiriman piranti lunak lan karya kita dhewe ing proses iki minangka tanpa alangan, ora lara, efisien, lan sing paling penting, nyenengake.
DevOps tansaya lara. Lan kita kesel nandhang sangsara. Lan supaya kabeh iki kelakon, kita ngandelake praktik evergreen: kolaborasi efektif, praktik aliran, lan sing paling penting, pamikiran sistem, amarga tanpa DevOps ora bisa digunakake.
Apa iku sistem?
Lan yen kita wis ngomong babagan pamikiran sistem, ayo ngelingake awake dhewe apa sistem kasebut.
Yen sampeyan minangka peretas revolusioner, mula sistem kasebut jelas ala. Iku awan sing nggantung lan meksa sampeyan nindakake perkara sing ora pengin sampeyan lakoni.
Saka sudut pandang sistem mikir, sistem minangka sakabehe sing dumadi saka bagean. Ing pangertèn iki, saben kita minangka sistem. Organisasi sing kita kerjakake yaiku sistem. Lan apa sing sampeyan lan aku mbangun diarani sistem.
Kabeh iki minangka bagéan saka siji sistem sosial-teknologi gedhe. Lan mung yen kita ngerti carane sistem sosio-teknologi iki bisa bebarengan, mung banjur kita bakal bisa kanggo saestu ngoptimalake soko ing prakara iki.
Saka perspektif sistem mikir, sistem nduweni macem-macem sifat sing menarik. Kapisan, dumadi saka perangan, tegese tumindake gumantung marang solah bawane. Kajaba iku, kabeh bagean kasebut uga saling gumantung. Pranyata manawa luwih akeh bagean sistem, luwih angel dimangerteni utawa prédhiksi prilaku.
Saka sudut pandang prilaku, ana fakta liyane sing menarik. Sistem kasebut bisa nindakake apa wae sing ora bisa ditindakake dening bagean individu.
Minangka Dr.. Russell Ackoff (salah siji saka ngedekke sistem mikir) ngandika, iki cukup gampang kanggo mbuktekaken karo eksperimen pikirane. Contone, sing ing kamar ngerti carane nulis kode? Ana akeh tangan, lan iki normal, amarga iki minangka salah sawijining syarat utama kanggo profesi kita. Apa sampeyan ngerti carane nulis, nanging tangan sampeyan bisa nulis kode kanthi kapisah saka sampeyan? Ana wong sing bakal ngomong: "Sampeyan dudu tanganku sing nulis kode, nanging otakku sing nulis kode." Apa otak sampeyan bisa nulis kode kanthi kapisah saka sampeyan? Inggih, mbokmenawa ora.
Otak minangka mesin sing apik tenan, kita ora ngerti 10% cara kerjane ing kana, nanging ora bisa digunakake kanthi kapisah saka sistem awak kita. Lan iki gampang kanggo mbuktekaken: mbukak tengkorak, njupuk metu otak, sijine ing ngarepe komputer, supaya wong nyoba kanggo nulis soko prasaja. "Hello, donya" ing Python, contone.
Yen sistem bisa nindakake apa wae sing ora ana bagean sing bisa ditindakake kanthi kapisah, mula iki tegese prilaku kasebut ora ditemtokake dening prilaku bagean kasebut. Apa banjur ditemtokake dening? Iki ditemtokake dening interaksi antarane bagean kasebut. Lan kanthi mangkono, luwih akeh bagean, luwih rumit interaksi, luwih angel mangertos lan prédhiksi prilaku sistem kasebut. Lan iki ndadekake sistem kasebut kacau, amarga owah-owahan apa wae, sanajan sing paling ora pati penting, ora katon ing bagean sistem bisa nyebabake asil sing ora bisa diramalake.
Sensitivitas iki kanggo kondisi awal pisanan ditemokake lan diteliti dening ahli meteorologi Amerika Ed Lorenz. Sabanjure, iki diarani "efek kupu-kupu" lan nyebabake pangembangan gerakan pamikiran ilmiah sing disebut "teori chaos." Teori iki dadi salah sawijining owah-owahan paradigma utama ing ilmu pengetahuan abad kaping 20.
Teori chaos
Wong sing sinau kekacauan diarani chaosologists.
Bener, alasan kanggo laporan iki yaiku, nggarap sistem distribusi sing rumit lan organisasi internasional sing gedhe, ing sawetara titik aku ngerti yen iki sing dakrasakake. Aku chaosologist. Iki minangka cara sing cerdas kanggo ujar: "Aku ora ngerti apa sing kedadeyan ing kene lan aku ora ngerti apa sing kudu ditindakake."
Aku mikir sing akeh sing uga kerep aran kaya iki, dadi sampeyan uga chaosologists. Aku ngajak sampeyan menyang guild chaosologists. Sistem sing sampeyan lan aku, kanca-kanca chaosologist, bakal sinau diarani "sistem adaptif kompleks."
Apa iku adaptasi? Kemampuan adaptasi tegese prilaku individu lan kolektif bagean ing sistem adaptif kasebut owah-owahan lan ngatur dhewe, nanggapi acara utawa rantai acara mikro ing sistem kasebut. Yaiku, sistem adaptasi karo owah-owahan liwat organisasi dhewe. Lan kemampuan kanggo ngatur dhewe adhedhasar sukarela, kerjasama desentralisasi saka agen otonomi gratis.
Properti liyane sing menarik saka sistem kasebut yaiku bisa diukur kanthi bebas. Apa sing temtu bisa narik kawigaten kita, minangka chaosologists-insinyur. Dadi, yen kita ngomong sing prilaku sistem Komplek ditemtokake dening interaksi saka bagean, banjur apa kita kudu kasengsem ing? Interaksi.
Ana rong temuan liyane sing menarik.
Kaping pisanan, kita ngerti manawa sistem kompleks ora bisa disederhanakake kanthi nyederhanakake bagean-bageane. Kapindho, siji-sijine cara kanggo nyederhanakake sistem sing kompleks yaiku kanthi nyederhanakake interaksi antarane bagean kasebut.
Kepiye carane kita sesambungan? Sampeyan lan aku kabeh bagean saka sistem informasi gedhe disebut masyarakat manungsa. Kita sesambungan liwat basa umum, yen kita duwe, yen kita nemokake.
Nanging basa dhewe minangka sistem adaptif sing kompleks. Dadi, supaya bisa sesambungan kanthi luwih efisien lan gampang, kita kudu nggawe sawetara protokol. Yaiku, sawetara urutan simbol lan tumindak sing bakal nggawe ijol-ijolan informasi ing antarane kita luwih gampang, luwih bisa ditebak, luwih bisa dingerteni.
Aku pengin ngomong yen tren menyang kerumitan, menyang adaptasi, menyang desentralisasi, menyang kekacauan bisa dilacak ing kabeh. Lan ing sistem sing sampeyan lan aku mbangun, lan ing sistem sing kita dadi bagean.
Lan ora dadi ora ana dhasar, ayo ndeleng kepiye sistem sing digawe ganti.
Sampeyan ngenteni tembung iki, aku ngerti. Kita ana ing konferensi DevOps, dina iki tembung iki bakal dirungokake kira-kira satus ewu kaping lan banjur kita bakal ngimpi ing wayah wengi.
Microservices minangka arsitektur piranti lunak pisanan sing muncul minangka reaksi marang praktik DevOps, sing dirancang kanggo nggawe sistem kita luwih fleksibel, luwih bisa diukur, lan njamin pangiriman terus-terusan. Kepiye carane dheweke nindakake iki? Kanthi nyuda volume layanan, nyuda ruang lingkup masalah sing diproses layanan kasebut, nyuda wektu pangiriman. Yaiku, kita nyuda lan nyederhanakake bagean saka sistem, nambah jumlahe, lan kanthi mangkono, kerumitan interaksi antarane bagean kasebut mesthi mundhak, yaiku, masalah anyar muncul sing kudu diatasi.
Microservices ora pungkasan, microservices, umume, wis wingi, amarga Serverless bakal teka. Kabeh server diobong, ora ana server, ora ana sistem operasi, mung kode eksekusi murni. Konfigurasi kapisah, negara kapisah, kabeh dikontrol dening acara. Kaendahan, karesikan, kasepen, ora ana acara, ora ana sing kedadeyan, tatanan lengkap.
Ing endi kerumitan? Kangelan, mesthi, ing interaksi. Pira fungsi sing bisa ditindakake dhewe? Kepiye carane sesambungan karo fungsi liyane? Antrian pesen, database, balancers. Kepiye carane nggawe maneh acara nalika ana kegagalan? Akeh pitakonan lan sawetara jawaban.
Microservices lan Serverless yaiku apa sing diarani hipsters Cloud Native. Iku kabeh babagan awan. Nanging maya uga diwatesi kanthi skalabilitas. Kita wis biasa mikir babagan iki minangka sistem sing disebarake. Nyatane, ing ngendi server panyedhiya awan manggon? Ing pusat data. Yaiku, kita duwe model terpusat, winates banget, disebarake ing kene.
Saiki kita ngerti manawa Internet of Things ora mung tembung gedhe sing sanajan miturut prediksi sing sederhana, milyaran piranti sing nyambung menyang Internet nunggu kita ing limang nganti sepuluh taun sabanjure. Sejumlah data sing migunani lan ora ana gunane sing bakal digabung menyang awan lan diunggah saka awan.
Awan ora bakal tahan, mula kita tambah akeh ngomong babagan sing diarani komputasi pinggir. Utawa aku uga seneng definisi apik saka "komputasi kabut". Iku katutup ing mistisisme romantisme lan misteri.
Komputasi kabut. Intine yaiku awan minangka gumpalan banyu, uap, es, lan watu sing terpusat. Lan kabut minangka tetesan banyu sing kasebar ing sekitar kita ing atmosfer.
Ing paradigma kabut, umume karya ditindakake dening tetesan kasebut kanthi mandiri utawa kanthi kolaborasi karo tetesan liyane. Lan padha nguripake menyang méga mung nalika padha tenan njaluk tenan dipencet.
Sing, maneh desentralisasi, otonomi, lan, mesthi, akeh sing wis ngerti ngendi kabeh iki arep, amarga sampeyan ora bisa ngomong bab desentralisasi tanpa nyebut blockchain.
Ana sing pracaya, iki sing wis nandur modhal ing cryptocurrency. Ana sing percaya nanging wedi, kaya aku, contone. Lan ana sing ora pracaya. Kene sampeyan bisa nambani beda. Ana teknologi, prakara anyar sing ora dingerteni, ana masalah. Kaya teknologi anyar, iki nuwuhake pitakon luwih akeh tinimbang sing dijawab.
Hype watara blockchain bisa dingerteni. Kanthi cepet-cepet emas, teknologi kasebut duwe janji sing luar biasa kanggo masa depan sing luwih cerah: luwih bebas, otonomi luwih akeh, kepercayaan global sing disebarake. Apa sing ora dikarepake?
Mula, luwih akeh insinyur ing saindenging jagad wiwit ngembangake aplikasi desentralisasi. Lan iki minangka kekuwatan sing ora bisa ditolak kanthi mung ngucap: "Ahh, pamblokiran mung minangka basis data sing disebarake kanthi ora apik." Utawa minangka skeptics kaya ngomong: "Ora ana aplikasi nyata kanggo blockchain." Yen dipikir-pikir, 150 taun kepungkur padha ngomong babagan listrik. Lan padha bener ing sawetara cara, amarga apa sing bisa ditindakake dening listrik saiki ora bisa ditindakake ing abad kaping 19.
Miturut cara, sing ngerti apa jenis logo ing layar? Iki Hyperledger. Iki minangka proyek sing dikembangake ing sangisore Yayasan Linux lan kalebu sakumpulan teknologi blockchain. Iki saestu kekuatan komunitas open source kita.
Chaos Engineering
Dadi, sistem sing dikembangake dadi saya tambah rumit, tambah semrawut, lan luwih adaptif. Netflix minangka pionir sistem layanan mikro. Dheweke ana ing antarane sing pertama ngerti iki, dheweke ngembangake piranti sing diarani Tentara Simian, sing paling misuwur yaiku . Dheweke nemtokake apa sing diarani .
Miturut cara, ing proses nggarap laporan, kita malah nerjemahake teks iki menyang basa Rusia, supaya pindhah menyang , maca, komentar, scold.
Sedhela, prinsip teknik chaos ngandika ing ngisor iki. Sistem distribusi sing rumit pancen ora bisa diprediksi lan pancen bug. Kesalahan ora bisa dihindari, tegese kita kudu nampa kesalahan kasebut lan nggarap sistem kasebut kanthi cara sing beda.
Kita dhewe kudu nyoba ngenalake kesalahan kasebut menyang sistem produksi kita supaya bisa nyoba sistem kita kanggo adaptasi sing padha, kemampuan iki kanggo organisasi dhewe, supaya bisa urip.
Lan sing ngganti kabeh. Ora mung carane kita miwiti sistem menyang produksi, nanging uga carane kita ngembangaken, carane kita nyoba. Ora ana proses stabilisasi utawa pembekuan kode, nanging ana proses destabilisasi sing terus-terusan. Kita nyoba mateni sistem kasebut lan ndeleng terus urip.
Protokol Integrasi Sistem Distribusi
Patut, iki mbutuhake sistem kita kanggo ngganti piye wae. Supaya dheweke dadi luwih stabil, dheweke butuh sawetara protokol anyar kanggo interaksi antarane bagean kasebut. Supaya bagean-bagean kasebut bisa sarujuk lan teka ing sawetara organisasi dhewe. Lan kabeh jinis alat anyar, protokol anyar muncul, sing diarani "protokol kanggo interaksi sistem sing disebarake."
Apa sing dakkandhakake? Pisanan, proyek . Sawetara nyoba nggawe protokol pelacakan sing disebarake umum, sing minangka alat sing pancen penting kanggo debugging sistem distribusi sing kompleks.
Salajengipun - . Kita ngomong yen kita ora bisa prédhiksi apa sing bakal kelakon ing sistem, yaiku, kita kudu nambah observability, observability. Opentracing kalebu kulawarga alat sing menehi observasi kanggo sistem kita. Nanging kita butuh observasi kanggo nemtokake manawa sistem kasebut tumindak kaya sing dikarepake utawa ora. Kepiye carane nemtokake prilaku sing dikarepake? Kanthi netepake sawetara kabijakan, sawetara aturan. Proyek Open Policy Agent lagi digunakake kanggo nemtokake set aturan iki ing spektrum saka akses menyang alokasi sumber daya.
Kaya sing wis dakkandhakake, sistem kita tambah akeh didorong acara. Serverless minangka conto sistem sing didorong acara. Supaya kita bisa nransfer acara antarane sistem lan trek mau, kita kudu sawetara basa umum, sawetara protokol umum kanggo carane kita pirembagan bab acara, carane kita ngirim menyang saben liyane. Iki sing diarani proyek .
Aliran owah-owahan sing terus-terusan sing ngrusak sistem kita, sing terus-terusan ora stabil, yaiku aliran artefak piranti lunak sing terus-terusan. Supaya kita bisa njaga aliran owah-owahan sing terus-terusan iki, kita butuh sawetara protokol umum sing bisa ngomong babagan apa artefak piranti lunak, cara dites, verifikasi apa sing wis dilewati. Iki sing diarani proyek . Yaiku, protokol metadata umum kanggo artefak piranti lunak.
Lan pungkasane, yen kita pengin sistem kita dadi mandiri, adaptif, lan diatur dhewe, kita kudu menehi hak kanggo identifikasi diri. Proyek diarani Iki persis apa sing ditindakake. Iki uga minangka proyek ing sangisore naungan Cloud Native Computing Foundation.
Kabeh proyek iki isih enom, kabeh butuh katresnan, validasi kita. Iki kabeh open source, testing kita, implementasine kita. Dheweke nuduhake arah teknologi.
Nanging DevOps ora tau utamane babagan teknologi, mesthine babagan kolaborasi antarane wong. Lan, miturut, yen kita pengin sistem sing dikembangake diganti, mula awake dhewe kudu ngganti. Nyatane, kita isih ganti; kita ora duwe pilihan akeh.
Ana sing apik banget Penulis Inggris Rachel Botsman, ing ngendi dheweke nulis babagan evolusi kepercayaan sajrone sejarah manungsa. Dheweke ujar manawa wiwitane, ing masyarakat primitif, kepercayaan lokal, yaiku, mung dipercaya wong sing kita kenal.
Banjur ana wektu sing dawa banget - wektu peteng nalika kapercayan dipusatake, nalika kita wiwit percaya marang wong-wong sing ora kita kenal adhedhasar kasunyatan manawa kita duwe institusi umum utawa negara sing padha.
Lan iki sing kita deleng ing donya modern kita: kapercayan dadi luwih disebarake lan didesentralisasi, lan adhedhasar kebebasan arus informasi, babagan kasedhiyan informasi.
Yen sampeyan mikir babagan iki, aksesibilitas iki, sing ndadekake kapercayan iki bisa ditindakake, sampeyan lan aku bakal ngetrapake. Iki tegese cara kita kolaborasi lan cara kita kudu owah, amarga organisasi IT sing terpusat lan hirarkis wis ora bisa digunakake maneh. Dheweke wiwit mati.
Dasar Organisasi DevOps
Organisasi DevOps sing cocog ing mangsa ngarep yaiku sistem adaptif sing terdesentralisasi sing kasusun saka tim otonom, saben wong sing otonom. Tim kasebut kasebar ing saindenging jagad, kolaborasi kanthi efektif kanthi nggunakake komunikasi asinkron, nggunakake protokol komunikasi sing transparan banget. Apik banget, ta? Masa depan sing apik banget.
Mesthi wae, ora ana sing bisa ditindakake tanpa owah-owahan budaya. Kita kudu duwe kepemimpinan transformasional, tanggung jawab pribadi, motivasi internal.
Iki minangka basis organisasi DevOps: transparansi informasi, komunikasi asinkron, kepemimpinan transformasional, desentralisasi.
Burnout
Sistem kita bagean lan sing kita mbangun tambah semrawut, lan iku angel kanggo kita manungsa kanggo ngrampungake karo pamikiran iki, iku angel kanggo nyerah khayalan kontrol. Kita nyoba terus ngontrol, lan iki asring nyebabake burnout. Aku ngomong iki saka pengalaman dhewe, aku uga diobong, aku uga dipatèni dening gagal unforeseen ing produksi.
Burnout occurs nalika kita nyoba kanggo ngontrol soko sing sipate uncontrollable. Nalika kita ngobong, kabeh bakal ilang makna amarga kita kelangan kepinginan kanggo nindakake sing anyar, kita dadi pertahanan lan miwiti mbela apa sing kita duwe.
Profesi teknik, kaya sing asring dakelingake, yaiku profesi kreatif sing paling penting. Yen kita kelangan kepinginan kanggo nggawe soko, banjur dadi awu, dadi awu. Wong kobong, kabeh organisasi kobong.
Ing panemuku, mung nampa daya kreatif saka kekacauan, mung mbangun kerjasama miturut prinsip-prinsip kasebut sing bakal mbantu kita supaya ora kelangan apa sing apik ing profesi kita.
Iki sing dakkarepake kanggo sampeyan: tresna marang pakaryanmu, tresna marang apa sing kita lakoni. Donya iki feed informasi, kita duwe pakurmatan kanggo dipakani. Dadi ayo sinau chaos, ayo dadi chaosologists, ayo nggawa nilai, nggawe sing anyar, uga, masalah, kaya sing wis dingerteni, ora bisa dihindari, lan nalika katon, kita mung bakal ngomong "Ops!" Lan masalah kasebut ditanggulangi.
Apa liyane saka Chaos Monkey?
Nyatane, kabeh instrumen kasebut isih enom. Piranti sing dibangun Netflix padha kanggo awake dhewe. Gawe alat dhewe. Waca prinsip teknik chaos lan tindakake prinsip kasebut tinimbang nyoba golek alat liyane sing wis digawe wong liya.
Coba mangertos carane sistem rusak lan wiwiti rusak lan ndeleng carane terus. Iki teka dhisik. Lan sampeyan bisa nggoleki alat. Ana kabeh jinis proyek.
Aku ora cukup ngerti wayahe nalika ngandika sing sistem ora bisa simplified dening simplifying komponen, lan langsung pindhah menyang microservices, kang menakake sistem dening simplifying komponen piyambak lan complicating interaksi. Iki ateges loro bagean sing mbantah saben liyane.
Bener, layanan mikro minangka topik sing kontroversial ing umum. Nyatane, nyederhanakake bagean nambah keluwesan. Apa sing diwenehake microservices? Padha menehi kita keluwesan lan kacepetan, nanging mesthi ora menehi kita gamblang. Padha nambah kangelan.
Dadi, ing filosofi DevOps, layanan mikro dudu barang sing apik?
Sembarang apik duwe sisih mbalikke. Keuntungan kasebut yaiku nambah keluwesan, ngidini kita nggawe owah-owahan luwih cepet, nanging nambah kerumitan lan mulane fragility kabeh sistem.
Nanging, apa sing luwih ditekanake: nyederhanakake interaksi utawa nyederhanakake bagean?
Penekanan, mesthi, kanggo nyederhanakake interaksi, amarga yen kita ndeleng iki saka sudut pandang babagan cara kerja karo sampeyan, mula, pisanan, kita kudu menehi perhatian kanggo nyederhanakake interaksi, lan ora nyederhanakake karya. saka saben kita dhewe. Amarga nyederhanakake karya tegese dadi robot. Ing kene ing McDonald's bisa digunakake kanthi normal yen sampeyan duwe instruksi: kene sampeyan sijine burger, kene sampeyan pour sauce ing. Iki ora bisa digunakake ing karya kreatif kita.
Apa bener kabeh sing sampeyan ucapake urip ing jagad tanpa kompetisi, lan kekacauan ing kana pancen apik banget, lan ora ana kontradiksi ing kekacauan iki, ora ana sing pengin mangan utawa mateni sapa wae? Kepiye carane kompetisi lan DevOps?
Inggih, iku gumantung ing jenis kompetisi kita ngomong bab. Apa babagan kompetisi ing papan kerja utawa kompetisi antarane perusahaan?
Babagan kompetisi layanan sing ana amarga layanan ora sawetara perusahaan. Kita nggawe jinis lingkungan informasi anyar, lan lingkungan apa wae ora bisa urip tanpa kompetisi. Ana kompetisi nang endi wae.
Netflix padha, kita njupuk minangka panutan. Yagene padha teka munggah karo iki? Amarga dheweke kudu kompetitif. Keluwesan lan kacepetan gerakan iki minangka syarat sing kompetitif banget; iki nyebabake kekacauan ing sistem kita. Tegese, kekacauan dudu perkara sing kita lakoni kanthi sadar amarga kita pengin, nanging kedadeyan amarga jagad nuntut. Kita mung kudu adaptasi. Lan lam, iku sabenere asil saka kompetisi.
Apa iki tegese kekacauan yaiku ora ana gol, kaya ngono? Utawa gol sing kita ora pengin ndeleng? Kita ana ing omah lan ora ngerti tujuane wong liya. Kompetisi, nyatane, amarga kita duwe tujuan sing jelas lan kita ngerti ing ngendi kita bakal mungkasi ing saben wektu sabanjure. Iki, saka sudut pandangku, minangka inti saka DevOps.
Uga dipikir ing pitakonan. Aku kabeh duwe tujuan sing padha: kanggo urip lan nindakake
kesenengan paling gedhe. Lan tujuan kompetitif saka organisasi apa wae padha. Kaslametan asring dumadi liwat kompetisi, ora ana sing bisa ditindakake.
Konferensi taun iki bakal njupuk Panggonan ing 7 Desember ing Technopolis. Kita nampa aplikasi kanggo laporan nganti 11 November. kita yen sampeyan pengin ngomong.
Registrasi kanggo peserta mbukak, tiket biaya 7000 rubles. Gabung karo kita!
Source: www.habr.com