Bagaimana untuk mengamalkan 'empat raja' revolusi diri

Seratus forum mengenai operasi dan penyelenggaraan, melalui temu bual dan jemputan untuk menyumbang, menjemput veteran dalam bidang operasi dan penyelenggaraan untuk memberikan pandangan yang mendalam dan bertembung bersama, dengan tujuan untuk membentuk Beberapa konsensus lanjutan menggalakkan industri untuk bergerak ke hadapan dengan lebih baik.

Dalam keluaran ini, kami menjemput Wang Mingsong, Bos Wang mencadangkan "Empat Peraturan" untuk amalan aplikasi asli awan, yang diiktiraf secara meluas dalam industri. Mulai tahun 2019, semua perniagaan IDC syarikat Boss Wang telah dipindahkan ke awan Skalanya tidak kecil, tetapi pasukan SRE sangat kecil, sedikit seperti NetFlix. Dalam kuliah ini, mari kita lihat cara operasi awan kanan dan penyelenggaraan berfungsi.

Ini adalah isu ke-7 "Forum Operasi dan Penyelenggaraan" yang rendah dan peringkat tinggi, mari mulakan!

Pratonton Masalah

• Saya pertama kali bertemu Boss Wang kerana perbincangan dalam kumpulan WeChat Boss Wang mencadangkan empat amalan aplikasi asli awan dan percaya bahawa selagi empat ini telah dilaksanakan , aplikasi itu pada dasarnya berasal dari awan Ahli kumpulan sangat bersetuju dan menamakannya "Wang Si Tiao" Bolehkah Boss Wang berkongsi intipati "Wang Si Tiao" dengan pembaca SRETalk?
• "Empat Raja" menyenaraikan beberapa amalan terbaik, yang memerlukan kerjasama R&D Apabila dilaksanakan dalam syarikat, saya tertanya-tanya adakah akan ada halangan? Bagaimana anda menyelesaikannya?
• Baru-baru ini, terdapat beberapa artikel yang mengatakan bahawa mereka mengukur ROI secara komprehensif dan berpendapat ia lebih menjimatkan kos untuk pergi ke awan, seperti artikel oleh bapa RoR, seperti En. Zou dari Tuyou Game dalam isu terakhir Forum Operasi dan Penyelenggaraan Baijia Nampaknya anda lebih cenderung untuk menggunakannya secara mendalam Yun, bolehkah anda berkongsi pendapat anda dengan semua orang.
• Terdapat artikel baru-baru ini "Masa depan operasi dan penyelenggaraan ialah kejuruteraan platform. Adakah anda bersetuju dengan pandangan ini? Apakah peranan dan sempadan yang pasukan anda ada dalam kejuruteraan platform? Bagaimanakah anda merancang untuk apa yang dipanggil kejuruteraan platform (terutamanya dalam persekitaran berbilang awan)?
• Di bawah mod kerja Boss Wang, saya rasa hanya orang yang sangat senior diperlukan darah segar terlalu muda untuk mengambil peranan sebagai jurulatih R&D. Pelan jangka masa bolehkah anda kongsikan bagaimana anda membina eselon anda?
• Kami tahu, Mingsong, anda sentiasa menjadi penyokong "revolusi diri operasi dan penyelenggaraan", iaitu "anti-manusia" Bolehkah anda bercakap tentang pemikiran di sebalik ini?

Pengenalan Tetamu

Sebelum bermula, sila perkenalkan diri anda kepada Boss Wang. Mari bincangkan tentang sejarah kerja anda, terutamanya pengalaman anda menggunakan awan, dan berikan anda beberapa maklumat latar belakang.

Sekitar tahun 2005, saya melakukan operasi dan penyelenggaraan BBS di sekolah, yang dianggap sebagai pengenalan. Selepas tamat pengajian, saya menyertai syarikat Internet utama (Nota editor: merujuk kepada Baidu) yang kini merosot, bermula dari operasi dan penyelenggaraan peringkat P1 merentas industri. Pada tahun 2010, saya melarikan diri dan menyertai syarikat permulaan Internet mudah alih Pada masa itu, saya pada asasnya melakukan segala-galanya daripada kabel rangkaian sistem ke IT bilik komputer Kitaran perolehan pelayan agak lama walaupun untuk syarikat kecil, jadi saya mula melakukannya pertimbangkan untuk menggunakan awan pada masa itu.

Sejak tahun 2011, saya telah menggunakan Suguang Cloud untuk satu tempoh masa Ia berdasarkan vmware dan pengalamannya sangat buruk adalah bahawa ia mungkin lebih cepat untuk memasang mesin daripada IDC. Kemudian rangkaian juga pelik, menyebabkan banyak masalah. Pada masa yang sama, saya juga menggunakan Shanda Cloud untuk tempoh masa yang lebih baik daripada Sugon, tetapi ia sebenarnya pada tahap vps. Rasanya lapisan vpc belum selesai. Saya tidak berani meletakkan sumber yang terlalu penting padanya, dan kemudian saya berhenti menggunakannya selepas ditarik berulang kali (mungkin kerana saya menggunakannya dengan cara yang salah dan tidak mudah untuk memantau).

Saya mula menggunakan ucloud pada tahun 2013. Ini terutamanya menggunakan mesin maya dan tidak banyak lagi. Tetapi produk vpc sepatutnya telah tersedia pada masa itu, dan beberapa perniagaan penting akan dialihkan.

Pada tahun 2014, saya mula menggunakan AWS kerana saya mula berniaga di luar negara. Pada tahun 2019, semua perniagaan IDC telah dipindahkan ke awan.

Soalan temu bual

Saya pertama kali bertemu Boss Wang kerana perbincangan dalam kumpulan WeChat Boss Wang mencadangkan empat amalan aplikasi asli awan dan percaya bahawa selagi empat ini telah dilaksanakan , aplikasi itu pada dasarnya berasal dari awan Ahli kumpulan sangat bersetuju dan menamakannya "Wang Si Tiao" Bolehkah Boss Wang berkongsi intipati "Wang Si Tiao" dengan pembaca SRETalk?

Saya telah meletakkan versi terperinci empat raja asli awan dalam repo Ma Gong Sweden (https://github.com/lipingtababa/cloud-native-best-practices Welcome). semua orang untuk membangkitkan isu, saya juga akan mengemas kini empat raja asli awan dari semasa ke semasa

Versi ringkasnya ialah:

1. Gunakan objek untuk menyimpan fail statik
2. Gunakan peranan Tidak boleh menggunakan ak sk
3. Gunakan perkhidmatan pengehosan sebanyak mungkin
4. Jangan simpan data pada pelayan

Titik permulaan empat item ini sebenarnya pada asasnya di sekitar ketiadaan kewarganegaraan dan data aplikasi Ia boleh dilakukan dengan selamat sambil mengambil kira kos, prestasi dan kebolehpercayaan Skop aplikasi tidak terhad kepada pengkomputeran awan juga boleh dilaksanakan sebagai rujukan.

Nota editor: Versi ringkas ini mungkin tidak kelihatan seperti banyak, tetapi ia sebenarnya mengandungi banyak perkara, saya cadangkan anda membacanya Jika anda tidak boleh mengklik pada pautan "Cloud Native King Si Tiao". pergi ke repo di atas dan cari Cloud Native di sana Wang Si Tiao.md sudah memadai.

"Empat Raja" menyenaraikan beberapa amalan terbaik, yang perlu diselaraskan oleh R&D Apabila dilaksanakan dalam syarikat, adakah terdapat sebarang halangan? Bagaimana anda menyelesaikannya?

Saya menghadapi beberapa halangan, tetapi itu kerana kami mempunyai keadaan kami sendiri.

Dalam satu sudut, kami tidak mempunyai pilihan selain pergi ke awan, dan kawalan kos merupakan sasaran yang sukar, jadi tiada laluan menenangkan lain untuk dipilih.

Kami adalah syarikat baharu yang dipisahkan daripada pasukan, jadi kami hanya memberi masa satu tahun untuk melakukan peralihan Matlamat yang diberikan oleh pihak pengurusan adalah untuk menjadikan beribu-ribu mesin yang sedia ada berjalan lancar berhijrah dengan lancar. Oleh kerana kami hanya menjalankan perniagaan di luar negara pada masa itu, kami tidak mempertimbangkan sama sekali penyelesaian bukan awan Walau bagaimanapun, pihak pengurusan masih memerlukan kos awan lebih rendah daripada menggunakan IDC sebelum ini.

Jika anda terus mengalihkan seni bina asal ke awan, sasaran kos yang ditetapkan oleh pihak pengurusan pasti tidak akan tercapai (Boss Feng dari Pigsty telah menulis banyak artikel serupa untuk menyokong pandangan IDC tradisional tentang awan. ( kelebihan kos), jadi hanya terdapat satu pilihan pada masa itu: untuk mengubah seni bina sedia ada untuk menyesuaikan diri dengan awan, supaya selepas penghijrahan, matlamat kos, prestasi dan kestabilan dapat dicapai.

Sebaliknya, biarkan R&D mengambil bahagian sepenuhnya dalam pemilihan model dan pengoptimuman kos, dan semua orang boleh mencapai kata sepakat.

Saya menghabiskan kira-kira setahun lebih awal untuk mula memilih awan awam, dan mengambil bahagian khas dalam latihan untuk mempelajari cara menggunakan awan dengan lebih baik, dan secara beransur-ansur membentuk metodologi saya sendiri. Sebelum penghijrahan, saya juga mengetuai ahli utama R&D untuk menyertai latihan yang berkaitan Selepas latihan, mereka dapat memahami bahawa banyak amalan saya adalah betul Selain itu, semasa penghijrahan sebenar, AWS juga menyediakan penyelesaian yang lebih profesional reka bentuk. Oleh itu, agak mudah untuk melaksanakan kandungan "empat raja", seperti:

1 Menyimpan data dalam EBS adalah sangat mahal, jadi menyimpan data dalam S3 adalah pilihan yang sangat menjimatkan perbandingan pelbagai penyelesaian, R&D telah membuat situasi yang sangat jelas ini, jadi akan ada kesediaan yang lebih besar untuk membuat pengubahsuaian program.

2. Peranan adalah keperluan keselamatan, kerana sdk AWS menyokongnya dengan sangat baik untuk soalan penyelidikan dan pembangunan.

3. Berkenaan perkhidmatan pengehosan, R&D sebenarnya tidak kisah sama ada operasi dan penyelenggaraan atau menggunakan perkhidmatan sedia ada. Selagi operasi dan penyelenggaraan kami dapat melepaskan obsesi kami, ini sudah memadai.

4. Jangan simpan data pada pelayan. Sebenarnya, kita telah melalui satu cabaran yang agak besar.

Penghijrahan kami kali ini adalah daripada persekitaran IDC dengan sokongan platform yang lengkap kepada AWS Dengan bantuan rakan kongsi AWS, seni bina baharu direka bentuk mengikut amalan terbaik AWS dan memenuhi tabiat dan keperluan penggunaan sebelumnya.

Tetapi kerana pembinaan semula, masih terdapat perbezaan dalam penggunaan. Kerana ASG digunakan, pelayan dibunuh secara langsung semasa pengecutan atau pemindahan kesalahan Jika data berterusan perlu disimpan di atasnya, ia akan hilang Jadi selepas masa ini, R&D pada dasarnya boleh menerima bahawa data perniagaan dalam talian tidak wujud pada pelayan .

Dan kerana reka bentuk ini, keperluan storan pelayan kami boleh menjadi sekecil mungkin. Apa-apa yang melebihi 100G memerlukan kelulusan saya. Menjimatkan banyak kos EBS

Kemudian, apabila pasukan R&D menggunakan K8S, mereka mempunyai pemahaman yang lebih mendalam tentang perkara ini Lagipun, data dalam bekas akan hilang.

Baru-baru ini, beberapa artikel menerangkan cara mereka mengukur ROI secara komprehensif dan berpendapat ia lebih menjimatkan kos untuk beralih ke awan, seperti artikel oleh bapa RoR dan En. Zou Tuyou Games dalam edisi terakhir Forum Operasi dan Penyelenggaraan, nampaknya Anda lebih cenderung untuk menggunakan awan secara mendalam Bolehkah anda berkongsi pendapat anda dengan semua orang?

Saya sebenarnya telah menyokong "amalan terbaik", tetapi saya juga telah berkomunikasi dengan semua orang bahawa "amalan terbaik ialah seni pelabur atau pengurusan maharaja", gunakan amalan terbaik. Kemungkinan besar bahawa anda perlu mengorbankan pekerjaan anda sendiri dan ramai orang lain untuk mencapai yang optimum Jika anda boleh mencapai yang optimum tanpa memusnahkan pekerjaan anda, pilihan anda akan menjadi lebih pelbagai.

Sama ada anda berpindah ke awan atau beralih ke awan bergantung pada minat anda, kekuatan sokongan pengurusan dan bagasi bersejarah. Jika saya berada dalam jawatan Encik Zou atau DHH, saya mungkin tidak berpegang pada pandangan semasa saya. Saya boleh berpegang pada awan:

Di satu pihak, ia adalah pengiktirafan pihak pengurusan telah mengalami kehilangan aset terbiar Saya telah melakukan pengoptimuman sumber IDC terbiar untuk masa yang lama , jadi saya menambah yang dibina sendiri di luar negara Bilik komputer juga tidak begitu mudah untuk pergi ke awan pada asasnya satu-satunya penyelesaian yang disokong oleh pihak pengurusan.

Sebaliknya, seperti yang dinyatakan di atas, secara kebetulan, seni bina kami telah diubah sepenuhnya, dan kos transformasi disokong oleh pihak pengurusan, jadi kami boleh menggunakan sepenuhnya kelebihan awan.

Akhir sekali, model perniagaan kami belum lagi mempunyai perniagaan beban tinggi dan tanpa negara yang stabil jangka panjang. Perniagaan seperti ini lebih sesuai untuk IDC tradisional.

Saya percaya bahawa kos untuk En. Zou atau DHH untuk mengubah seni bina sistem sedia ada mereka adalah terlalu tinggi Walaupun ia boleh mengurangkan kos buruh bahagian operasi dan penyelenggaraan, ia mungkin sukar diperoleh sokongan, kerana ini masih Melibatkan kepentingan jabatan lain.

Tetapi jika ia adalah syarikat baharu atau projek baharu, saya percaya tiada senario yang lebih sesuai daripada awan Pilih vendor awan yang sesuai dan pakai seni bina asli awan untuk melaksanakan perniagaan, supaya keseluruhannya perniagaan boleh dipertingkatkan dari segi prestasi dan kos adalah anjal.

Ramai kawan mengadu tentang cloud killing, locking dan seumpamanya. Tetapi dari perspektif pelabur atau pengurusan, semua elemen adalah untuk mencapai keuntungan perniagaan People/cloud/IDC, dan lain-lain adalah semua elemen untuk mencapai perniagaan Jika pelabur ingin mencapai perniagaan, mereka bukan sahaja perlu membayar untuk faktor-faktor ini, tetapi juga Mampu mendapatkan elemen yang memenuhi keperluan anda tepat pada masanya (ini lebih penting). Mendapatkan elemen awan tidak boleh menjadi lebih mudah. ​​Kualiti dan harga produk adalah agak standard Anda boleh membayar untuknya dengan beberapa klik, tetapi anda boleh berhenti menggunakannya pada bila-bila masa. Tetapi bagaimana dengan orang? Sukar untuk mendapatkan orang, dan kualitinya sukar ditentukan. Ia tidak diseragamkan, dan akan berlaku turun naik harga (kenaikan gaji Anda tidak boleh diberhentikan secara santai, dan anda tidak akan digantikan oleh seseorang yang benar-benar). sama apabila anda meninggalkan kerja. Orang ramai boleh menjadi sangat kreatif, tetapi apabila ia berkaitan dengan penyeragaman dan perkara yang membosankan mekanikal, orang tidak boleh menjadi lawan mesin, apatah lagi perkhidmatan SaaS.

Mengenai situasi Encik Zou, jika pasukan perniagaan mereka tidak mahu mengubah seni bina program, pilihan semasa beliau ialah amalan terbaik: untuk perniagaan yang stabil dan beban tinggi, pilih IDC dengan kelebihan dalam kos, dan menyewa mesin dan bukannya Membeli Penghijrahan perniagaan elastik ke awan.

Untuk Basecamp 37signals, model harga produk menentukan bahawa agak menyusahkan mereka untuk berhijrah ke awan. Kebanyakan perkhidmatan SaaS kini dibayar berdasarkan penggunaan atau bilangan pengguna, tetapi Basecamp terutamanya menjual pakej tanpa had, yang hanya $199 sebulan. Model penentuan harga ini bermakna mereka tidak boleh menggunakan sepenuhnya keanjalan awan untuk mengaut keuntungan, dan hanya boleh terlebih menempah sumber berharga rendah. Jika model harga ini tidak diubah, tidak kira bagaimana seni bina dioptimumkan, ia mungkin tidak sesuai untuk awan.

Terdapat artikel terbaru "Masa depan operasi dan penyelenggaraan adalah kejuruteraan platform Adakah anda bersetuju dengan pandangan ini? Apakah peranan dan sempadan yang pasukan anda ada dalam kejuruteraan platform? Bagaimanakah anda merancang untuk apa yang dipanggil kejuruteraan platform (terutamanya dalam persekitaran berbilang awan)?

Adakah ia ditulis oleh Ruan Yifeng atau Charity Majors? Tetapi saya tidak pernah membaca dua artikel ini sebelum ini, dan saya hanya melihatnya secara ringkas. Saya tidak bersetuju sepenuhnya dengan ini, dan saya secara peribadi tidak akan cuba melakukan kejuruteraan platform dalaman.

Pertama sekali, mari bercakap tentang perkara yang saya tidak bersetuju: artikel itu mempunyai beberapa salah faham tentang konsep.

Pertama sekali, DevOps bukanlah kedudukan yang saya telah cuba memahaminya untuk masa yang lama, dan perasaan terakhir ialah ia adalah model pembangunan. Tetapi teras model pembangunan ini ialah R&D, dan semua elemen mesti menumpukan pada perkhidmatan lelaran R&D yang cekap. Artikel itu pada mulanya percaya bahawa DevOps adalah kedudukan, tetapi kemudiannya percaya bahawa kedudukan ini adalah untuk pembangunan perniagaan, saya fikir ini adalah pemahaman yang tidak sesuai.

Kedua, operasi dan penyelenggaraan mempunyai banyak perkara yang perlu diterokai pada masa hadapan. Transformasi bukanlah topik baru Semua orang telah lama memahami bahawa industri operasi dan penyelenggaraan adalah industri yang terbenam Dalam tempoh sepuluh tahun yang lalu, banyak operasi dan penyelenggaraan telah cuba mengubah dan mencari jalan keluar untuk langkah seterusnya sedang cuba melibatkan diri dalam CI/CD, dan ada yang cuba melibatkan diri dalam CI/CD Ada yang cuba melakukan penyelidikan dan pembangunan pemantauan, ada yang cuba membangunkan platform operasi dan penyelenggaraan automatik, ada yang cuba melibatkan diri dalam bidang baharu (. seperti K8, data besar, AI, pengkomputeran awan, dll.), dan sesetengahnya cuba beralih ke subprojek lain (seperti DBA, keselamatan rangkaian) ).

Dapat dilihat bahawa banyak daripada transformasi ini menyediakan model pembangunan DevOps.

Kejuruteraan platform mungkin model pelaksanaan, tetapi dengan kekuatan produk dan tahap R&D kumpulan operasi dan penyelenggaraan, saya khuatir melakukan kejuruteraan platform sendiri hanya boleh menghiburkan diri sendiri, malah kestabilan tidak dapat dijamin, yang hanya akan menambah beban mungkin. Walau bagaimanapun, jika pasukan pengeluaran dan penyelidikan yang lebih profesional diperkenalkan untuk melakukannya, di satu pihak, sukar untuk mendapatkan sokongan jika ia tidak menjalankan perniagaan dengan betul dan tiada kaitan dengan pendapatan perniagaan utama , ia hanya satu platform untuk kegunaan sendiri Tidak menjimatkan ramai orang untuk membuat produk tanpa pendapatan, dan lebih sukar untuk mendapatkan sokongan Apatah lagi, pendekatan ini tidak mempunyai rasa penyertaan dalam operasi dan penyelenggaraan sedia ada, dan ia tidak boleh dianggap sebagai transformasi.

Jadi, saya rasa pendekatan yang betul ialah menggunakan platform dan alatan yang matang (sumber terbuka/dibina sendiri berbayar, SaaS boleh digunakan, anda boleh melakukan beberapa penyesuaian dan pembangunan sekunder berdasarkan platform ini, tetapi jangan 't mencipta semula roda.

Akhir sekali, pemahaman saya tentang platform dalam artikel itu juga berbeza.

Di satu pihak, platform itu sendiri boleh disediakan dalam bentuk SaaS dan tidak memerlukan integrasi sekunder Sebab utama sekarang ialah persekitaran SaaS domestik tidak baik dan perkhidmatan perisian tidak memberi perhatian integrasi dan keserasian bersama, tetapi lebih suka untuk berkembang lebih besar. Apabila kita melihat ke luar negara, kita akan mendapati terdapat banyak SaaS atau perisian dalam bidang khusus di luar negara, yang sangat baik dan boleh disepadukan dengan perisian lain Ekosistemnya sangat baik, jadi penyepaduan mudah untuk dikonfigurasikan, dan tidak ada banyak beban kerja untuk pembangunan menengah.

Sebaliknya, pengguna platform harus R&D, dan R&D seharusnya boleh menggunakannya secara langsung tanpa memerlukan operasi dan penyelenggaraan untuk menyampaikan atau meluluskannya.

Jadi pada masa hadapan kita benar-benar perlu menggunakan platform Ia adalah platform yang dibuat oleh pasukan produksi dan penyelidikan profesional, bukan mainan yang dibuat oleh diri sendiri; pasukan pengeluaran dan penyelidikan, dan bukannya disekat oleh operasi dan penyelenggaraan.

Jadi untuk kejuruteraan platform, saya memilih untuk menggunakan perisian matang atau perkhidmatan SaaS secara aktif, dan menyediakannya untuk kegunaan terus oleh pasukan pengeluaran dan penyelidikan sebanyak mungkin.

Pengoperasian dan penyelenggaraan hanya membuat beberapa pusat pemeriksaan yang diperlukan berdasarkan kos dan keselamatan, dan mengawalnya melalui dasar, kebenaran dan audit untuk memastikan pasukan pengeluaran dan penyelidik boleh menggunakannya dengan betul.

Di bawah model kerja Boss Wang, saya rasa hanya orang yang sangat senior diperlukan Darah segar terlalu muda untuk mengambil peranan sebagai jurulatih R&D, tetapi tanpa darah segar, ia tidak boleh jangka panjang Weiji, bolehkah anda berkongsi cara anda membina eselon anda?

Ini soalan yang bagus kerana saya juga belum menyelesaikannya. Ini bukan masalah dengan model berfungsi ini.

Banyak syarikat dan banyak jenis pekerjaan mempunyai permintaan untuk bakat senior, dan mereka semua menghadapi masalah yang sama yang saya hadapi sekarang. Apakah jenis kerja yang tidak memerlukan bakat senior? Saya fikir kandungan kerja telah sangat standard, keperluan syarikat tidak tinggi, dan sesiapa sahaja boleh memberi arahan yang jelas mengikut keperluan dan melakukannya dengan baik. Mesin pun boleh buat.

Encik Zou berkata bahawa operasi dan penyelenggaraan tradisional adalah serupa dengan pembersihan. Kandungan kerja adalah penting tetapi nilainya tidak tinggi. Saya cukup bersetuju dengan kenyataan ini. Inilah dilema yang kita hadapi sekarang dalam operasi dan penyelenggaraan. Jadi adakah pasukan pembersihan membangunkan alat pembersihan mereka sendiri atau adakah mereka membelinya?

Oleh kerana saya menggunakan sejumlah besar produk matang dan perkhidmatan luaran, saya boleh mengeluarkan tugas pembersihan dengan lebih stabil, sama seperti membersihkan menggunakan pelbagai alat pembersihan automatik dan separa automatik. Tetapi anda tidak perlu risau tentang kekurangan keupayaan pembersihan seseorang yang membawa kepada mengemop yang tidak bersih, atau kekurangan profesionalisme yang membawa kepada imbasan mudah dan kemudian menyerahkan tugas. Walaupun pembersihan memerlukan lebih banyak pembelajaran dan kesukaran untuk mengendalikan alat ini dengan baik berbanding alat tradisional, keseluruhan SOP adalah kurang daripada sebelumnya kerana alat matang melindungi butiran.

Jadi, jangan buang masa untuk kandungan kerja bernilai rendah ini dilengkapkan dengan perisian profesional atau SaaS. Mereka mempunyai skala ekonomi, fungsi yang baik dan SLA. Kita harus menumpukan kerja kita pada bidang yang perniagaan, pengurusan dan pelabur lebih mengambil berat tentangnya.

Kami tahu bahawa Bos Wang sentiasa menjadi penyokong "revolusi diri operasi dan penyelenggaraan", iaitu "anti-manusia" Bolehkah anda bercakap tentang pemikiran di sebalik ini?

Hakikat yang kita lihat sekarang ialah operasi dan penyelenggaraan bukanlah industri yang berkembang pesat Kebanyakan syarikat tidak mempunyai jabatan operasi dan penyelenggaraan yang besar untuk menyokong operasi sistem syarikat malah hanya memerlukan satu orang, yang juga akan bertanggungjawab untuk IT, pengurusan rangkaian, keselamatan dan tugas-tugas lain. Kami tidak mempunyai ruang untuk penambahbaikan Terdapat sangat sedikit pengarah operasi dan penyelenggaraan, dan pengurus operasi dan penyelenggaraan pada dasarnya adalah had Dengan bilangan orang yang saya uruskan sekarang, anda boleh memanggil saya pengarah operasi dan penyelenggaraan.

Industri juga berada dalam keadaan yang sama sekarang Sebilangan besar kursus latihan menyediakan operasi dan penyelenggaraan yang cepat, yang mencukupi dan murah. Terdapat sangat sedikit operasi dan penyelenggaraan pertengahan hingga tinggi laluan kerjaya dan pembentukan pasaran bakat yang sihat. Oleh itu, kedudukan pasaran operasi dan penyelenggaraan kami sebenarnya adalah pelbagai "Teknologi yang tidak menulis kod perniagaan" mungkin kedudukan kami yang paling tepat.

Mengikut konsep DevOps, kita harus mempercepatkan penyampaian perniagaan dan menyediakan perkhidmatan yang baik, dan bukannya menambah kekacauan pada pengeluaran dan penyelidikan. Tetapi maksud dan kerja operasi dan penyelenggaraan bukan hanya mengenai DevOps Di sinilah pandangan saya berbeza daripada yang lain.

Di satu pihak, operasi dan penyelenggaraan ialah "anjing pemerhati" aset digital syarikat Dari perspektif ini, operasi dan penyelenggaraan mewakili kepentingan pengurusan dan pelabur, melindungi aset digital syarikat dengan betul, dan memastikan Ia. boleh digunakan dengan betul, memenuhi pelbagai keperluan kawal selia, dan mengambil bahagian dalam pelbagai audit dalaman. Ia adalah semakan dan imbang pihak pengurusan ke atas pasukan pengeluaran dan penyelidikan. Ini sebenarnya maksud operasi dan penyelenggaraan awal.

Sebaliknya, negara menikmati makanan. Keperluan kawal selia menjadi semakin ketat Sama ada keselamatan rangkaian, keselamatan data atau perlindungan maklumat peribadi, kakitangan yang berdedikasi dikehendaki bertanggungjawab untuk kerja yang berkaitan. Bagi perusahaan berskala kecil, tugas-tugas ini mesti dilakukan serentak dengan operasi dan penyelenggaraan, terutamanya keselamatan data, yang mesti terlibat secara langsung dalam pengendalian dan penyelenggaraan aset digital. Ini adalah keperluan untuk operasi dan penyelenggaraan dalam era baharu.

Jadi, jika anda ingin memahami perkara ini, anda akan mendapati bahawa Devops dan platform semuanya adalah sebahagian kecil daripada kerja operasi dan penyelenggaraan pasukan tidak digabungkan dan menjalankan tugas dengan baik dalam perspektif pengurusan dan penyeliaan kami.

Bacaan lanjutan

• ​​Forum Operasi dan Penyelenggaraan No. 6: Tuyou Zou Yi - Bagaimana untuk melakukan operasi dan penyelenggaraan syarikat kecil dan sederhana?
• ​​Forum Operasi dan Penyelenggaraan No. 5: Du Xiaoman dan Chen Cunli "komander" berusia 20 tahun bercakap tentang operasi dan penyelenggaraan, prestasi dan pertumbuhan​​
• Forum Operasi dan Penyelenggaraan Ratusan Forum No. 4: Shao Haiyang sekali lagi - veteran Linux 25 tahun bercakap tentang Lapan Kehormatan dan Lapan Aib DevOps​
• ​​Forum Operasi dan Penyelenggaraan No. 3 : Lai Wei-Cara menguruskan nasib Pekerjaan Wei adalah stabil​​
• ​​Isu ke-2 Seratus Forum Mengenai Operasi dan Penyelenggaraan: Nie An dari Zuoyebang - Bagaimana mengubah operasi dan penyelenggaraan, dengar kepada idea OPaS Zuoyebang
• ​​Isu Pertama Forum Operasi dan Penyelenggaraan: Jingyuan-Geometri Operasi dan Penyelenggaraan​​

Atas ialah kandungan terperinci Bagaimana untuk mengamalkan 'empat raja' revolusi diri. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!