Amalan Uber: Beberapa pengalaman dalam mengendalikan dan menyelenggara sistem teragih berskala besar

Artikel ini ditulis oleh jurutera Uber Gergely Orosz Alamat asal ialah: https://blog.pragmaticengineer.com/operating-a-high-scale-distributed-system/

<.>Sejak beberapa tahun kebelakangan ini, saya telah membina dan mengendalikan sistem pengedaran yang besar: sistem pembayaran Uber. Dalam tempoh ini, saya belajar banyak tentang konsep seni bina yang diedarkan dan menyaksikan sendiri cabaran menjalankan sistem beban tinggi dan ketersediaan tinggi (sistem masih jauh daripada selesai apabila ia dibangunkan, dan cabaran menjalankannya dalam talian sebenarnya adalah lebih hebat lagi). Membina sistem itu sendiri adalah satu usaha yang menarik. Merancang cara sistem akan mengendalikan peningkatan trafik 10x/100x, memastikan ketahanan data, mengendalikan kegagalan perkakasan, dll. semuanya memerlukan kebijaksanaan. Walau apa pun, mengendalikan sistem teragih yang besar telah menjadi pengalaman yang membuka mata saya.

Semakin besar sistem, semakin jelas hukum Murphy tentang "apa yang boleh salah, akan menjadi salah". Terdapat banyak pembangun menggunakan dan menggunakan kod dengan kerap, berbilang pusat data terlibat, dan sistem digunakan oleh sebilangan besar pengguna global, semakin besar kebarangkalian ralat tersebut. Sejak beberapa tahun kebelakangan ini, saya telah mengalami pelbagai kegagalan sistem, kebanyakannya mengejutkan saya. Ada yang datang daripada perkara yang boleh diramal, seperti kegagalan perkakasan atau pepijat yang kelihatan tidak berbahaya, serta kabel pusat data yang digali dan berbilang kegagalan lata berlaku serentak. Saya telah mengalami berpuluh-puluh gangguan perniagaan di mana beberapa bahagian sistem tidak berfungsi dengan betul, mengakibatkan kesan perniagaan yang besar.

Artikel ini ialah koleksi amalan yang saya rumuskan semasa bekerja di Uber yang boleh mengendalikan dan menyelenggara sistem besar dengan berkesan. Pengalaman saya tidak unik - orang yang bekerja pada sistem bersaiz serupa telah melalui perjalanan yang serupa. Saya bercakap dengan jurutera di Google, Facebook dan Netflix, dan mereka berkongsi pengalaman dan penyelesaian yang serupa. Banyak idea dan proses yang digariskan di sini harus digunakan pada sistem bersaiz serupa, sama ada berjalan pada pusat data mereka sendiri (seperti yang dilakukan oleh Uber dalam kebanyakan kes) atau dalam awan (Uber kadangkala menggunakan bahagian perkhidmatannya secara elastik ke awan) yang lebih tinggi). Walau bagaimanapun, amalan ini mungkin terlalu keras untuk sistem yang lebih kecil atau kurang kritikal misi.

Terdapat banyak perkara yang perlu dibincangkan - Saya akan membincangkan topik berikut:

Memantau
• Bertugas, pengesanan anomali dan memberi amaran
• Proses pengurusan kerosakan dan insiden
• Analisis bedah siasat, semakan insiden dan budaya penambahbaikan berterusan
• Latihan kegagalan, perancangan kapasiti dan ujian kotak hitam
• SLO, SLA dan laporannya
• SRE Sebagai pasukan bebas
• Kebolehpercayaan sebagai pelaburan berterusan
• Bacaan yang lebih disyorkan

Pemantauan

Untuk mengetahui sama ada sistem adalah sihat, kita perlu menjawab " Adakah sistem saya berfungsi dengan baik? Untuk melakukan ini, pengumpulan data pada bahagian penting sistem adalah penting. Untuk sistem teragih dengan berbilang perkhidmatan yang dijalankan pada berbilang komputer dan pusat data, sukar untuk menentukan perkara utama yang perlu dipantau.

Pemantauan Kesihatan Infrastruktur Jika satu atau lebih komputer/mesin maya terlebih muatan, sesetengah bahagian sistem yang diedarkan mungkin merosot. Status kesihatan mesin, penggunaan CPU dan penggunaan memori adalah kandungan asas yang patut diawasi. Sesetengah platform boleh mengendalikan kejadian pemantauan dan penskalaan automatik ini di luar kotak. Di Uber, kami mempunyai pasukan infrastruktur teras yang sangat baik yang menyediakan pemantauan infrastruktur dan makluman di luar kotak. Tidak kira bagaimana ia dilaksanakan di peringkat teknikal, apabila terdapat masalah dengan contoh atau infrastruktur, platform pemantauan perlu menyediakan maklumat yang diperlukan.

Pemantauan kesihatan perkhidmatan: trafik, ralat, kependaman. Kami selalunya perlu menjawab soalan "Adakah perkhidmatan bahagian belakang ini sihat?" Memerhati perkara seperti trafik permintaan, kadar ralat dan kependaman titik akhir mengakses titik akhir semuanya boleh memberikan maklumat berharga tentang kesihatan perkhidmatan anda. Saya lebih suka mempunyai ini semua dipaparkan pada papan pemuka. Apabila membina perkhidmatan baharu, anda boleh belajar banyak tentang sistem dengan menggunakan pemetaan respons HTTP yang betul dan memantau kod yang berkaitan. Oleh itu, memastikan bahawa 4XX dikembalikan pada ralat klien, dan 5xx pada ralat pelayan, adalah mudah untuk dibina dan mudah untuk ditafsirkan.

Pemantauan kependaman patut difikirkan lagi. Untuk perkhidmatan pengeluaran, matlamatnya adalah untuk majoriti pengguna akhir mempunyai pengalaman yang baik. Ternyata mengukur kependaman purata bukanlah metrik yang sangat baik kerana purata ini boleh menyembunyikan peratusan kecil permintaan kependaman tinggi. Mengukur p95, p99 atau p999 - kependaman yang dialami oleh permintaan persentil ke-95, ke-99 atau ke-99.9 - ialah metrik yang lebih baik. Nombor ini membantu menjawab soalan seperti "Berapa pantaskah 99% permintaan orang?" atau "Seberapa lambat kelewatan yang dialami oleh sekurang-kurangnya seorang dalam 1,000?" (p999). Bagi mereka yang lebih berminat dengan topik ini, artikel primer tertunda ini menyediakan bacaan lanjut.

Ia boleh dilihat dengan jelas daripada rajah bahawa perbezaan dalam kependaman purata, p95, dan p99 adalah agak besar. Jadi kependaman purata mungkin menutup beberapa isu.

Terdapat banyak kandungan yang lebih mendalam mengenai pemantauan dan kebolehmerhatian. Dua sumber yang patut dibaca ialah buku SRE Google dan bahagian mengenai Empat Metrik Emas Pemantauan Sistem Teragih. Mereka mengesyorkan bahawa jika anda hanya boleh mengukur empat metrik untuk sistem yang dihadapi pengguna anda, fokus pada trafik, ralat, kependaman dan ketepuan. Untuk bahan yang lebih pendek, saya mengesyorkan e-buku Kebolehcerapan Sistem Teragih daripada Cindy Sridharan, yang merangkumi alatan berguna lain seperti pengelogan peristiwa, metrik dan pengesanan amalan terbaik.

Pemantauan penunjuk perniagaan. Memantau modul perkhidmatan boleh memberitahu kami cara modul perkhidmatan berjalan seperti biasa, tetapi ia tidak dapat memberitahu kami sama ada perniagaan itu berfungsi seperti yang diharapkan dan sama ada ia "berniaga seperti biasa". Dalam sistem pembayaran, persoalan utama ialah, "Bolehkah orang menggunakan kaedah pembayaran tertentu untuk membuat pembayaran?". Mengenal pasti acara perniagaan dan memantaunya adalah salah satu langkah pemantauan yang paling penting.

Walaupun kami mewujudkan pelbagai pemantauan, beberapa masalah perniagaan masih tidak dapat dikesan, yang menyebabkan kami kesakitan dan akhirnya mewujudkan pemantauan penunjuk perniagaan. Kadangkala semua perkhidmatan kami kelihatan berjalan seperti biasa, tetapi ciri produk utama tidak tersedia! Pemantauan seperti ini sangat berguna untuk organisasi dan bidang kami. Oleh itu, kami terpaksa meletakkan banyak pemikiran dan usaha untuk menyesuaikan sendiri jenis pemantauan ini, berdasarkan timbunan teknologi pemerhatian Uber.

Nota Penterjemah: Kami benar-benar merasakan perkara yang sama tentang pemantauan penunjuk perniagaan Pada masa lalu, kami kadangkala mendapati bahawa semua perkhidmatan adalah normal di Didi, tetapi perniagaan tidak berfungsi dengan baik. Sistem Polaris yang sedang kami bina untuk memulakan perniagaan direka khusus untuk menangani masalah ini. Rakan-rakan yang berminat boleh meninggalkan saya mesej di latar belakang akaun rasmi, atau menambah rakan picobyte saya untuk berkomunikasi dan mencubanya.

Oncall, Pengesanan Anomali dan Makluman

Pemantauan ialah alat yang hebat untuk mendapatkan cerapan tentang keadaan semasa sistem anda. Tetapi ini hanyalah batu loncatan untuk mengesan masalah secara automatik dan meningkatkan makluman untuk orang ramai mengambil tindakan.

Oncall sendiri ialah topik yang luas - Majalah Increment merangkumi banyak aspek dalam "Isu Atas Panggilan"nya. Pendapat saya yang kuat ialah jika anda mempunyai mentaliti "anda membinanya, anda memilikinya", OnCall akan mengikutinya. Pasukan yang membina perkhidmatan memilikinya dan bertanggungjawab untuk memanggil mereka. Pasukan kami bertugas untuk perkhidmatan pembayaran. Oleh itu, apabila penggera berlaku, jurutera yang bertugas bertindak balas dan menyemak butiran. Tetapi bagaimana anda beralih daripada pemantauan kepada amaran?

Mengesan anomali daripada data pengawasan ialah satu cabaran yang sukar dan kawasan yang membolehkan pembelajaran mesin bersinar. Terdapat banyak perkhidmatan pihak ketiga yang menyediakan pengesanan anomali. Mujur sekali lagi, pasukan kami mempunyai pasukan pembelajaran mesin dalaman untuk bekerjasama dan mereka menyesuaikan penyelesaian kepada penggunaan Uber. Pasukan Observability yang berpangkalan di New York menulis artikel berguna yang menerangkan cara pengesanan anomali Uber berfungsi. Dari perspektif pasukan saya, kami menolak data pemantauan ke saluran paip pasukan itu dan mendapat makluman dengan tahap keyakinan masing-masing. Kami kemudian memutuskan sama ada kami perlu menghubungi jurutera.

Apabila penggera dicetuskan ialah soalan yang menarik. Terlalu sedikit makluman boleh bermakna kehilangan gangguan yang memberi kesan. Terlalu banyak boleh menyebabkan tidur malam dan keletihan. Mengesan dan mengelaskan penggera dan mengukur nisbah isyarat kepada hingar adalah penting untuk menala sistem penggera. Menyemak makluman dan membenderakannya sebagai boleh diambil tindakan, kemudian mengambil langkah untuk mengurangkan makluman yang tidak boleh diambil tindakan, merupakan langkah yang baik ke arah mencapai penggiliran atas panggilan yang mampan.

Contoh papan pemuka panggilan dalaman yang digunakan oleh Uber, dibina oleh pasukan Pengalaman Pembangun Uber di Vilnius.

Pasukan Uber Dev Tools di Vilnius membina alat panggilan yang kemas yang kami gunakan untuk menganotasi makluman dan menggambarkan peralihan panggilan. Pasukan kami menjalankan semakan mingguan bagi peralihan atas panggilan terakhir, menganalisis titik kesakitan dan meluangkan masa untuk menambah baik pengalaman panggilan, minggu demi minggu.

Nota Penterjemah: Pengagregatan peristiwa penggera, pengurangan hingar, penjadualan, tuntutan, peningkatan, kerjasama, strategi tolak fleksibel, tolakan berbilang saluran dan sambungan dengan IM adalah keperluan yang sangat biasa dan boleh Rujuk kepada produk FlashDuty, alamat pengalaman: https://console.flashcat.cloud/

Proses pengurusan kesalahan dan insiden

Bayangkan: anda adalah jurutera yang bertugas minggu ini. Pada tengah malam, penggera membangunkan anda. Anda menyiasat sama ada gangguan pengeluaran berlaku. Oops, nampaknya ada sesuatu yang tidak kena dengan beberapa bahagian sistem. Apa sekarang? Pemantauan dan amaran sebenarnya berlaku.

Untuk sistem kecil, gangguan mungkin bukan masalah besar dan jurutera yang bertugas boleh memahami apa yang berlaku dan sebabnya. Mereka biasanya mudah difahami dan mudah dikurangkan. Untuk sistem yang kompleks dengan berbilang perkhidmatan (mikro) dan ramai jurutera yang menolak kod kepada pengeluaran, hanya menunjukkan dengan tepat di mana isu yang berpotensi berlaku boleh menjadi cukup mencabar. Mempunyai beberapa proses standard untuk membantu menyelesaikan masalah ini boleh membuat perbezaan yang besar.

Buku panduan yang dilampirkan pada amaran yang menerangkan langkah-langkah mitigasi mudah sebagai barisan pertahanan pertama. Bagi pasukan yang mempunyai buku panduan yang baik, walaupun jurutera yang bertugas tidak mempunyai pemahaman yang mendalam tentang sistem, ia jarang menjadi masalah. Buku larian perlu sentiasa dikemas kini, dikemas kini dan menggunakan mitigasi baru untuk menangani kegagalan apabila ia berlaku.

Nota Penterjemah: Konfigurasi peraturan penggera Nightingale dan Grafana boleh menyokong medan tersuai, tetapi beberapa medan tambahan disediakan secara lalai, seperti RunbookUrl Intinya adalah untuk menyampaikan kepentingan manual SOP. seks. Di samping itu, dalam sistem pengurusan kestabilan, sama ada peraturan penggera telah pratetap RunbookUrl ialah penunjuk kesihatan penggera yang sangat penting.

Setelah terdapat lebih daripada beberapa pasukan menggunakan perkhidmatan, kesalahan berkomunikasi di seluruh organisasi menjadi kritikal. Saya bekerja dalam persekitaran di mana beribu-ribu jurutera menggunakan perkhidmatan yang mereka kembangkan kepada pengeluaran mengikut budi bicara mereka sendiri, yang berpotensi beratus-ratus penempatan sejam. Arahan perkhidmatan yang kelihatan tidak berkaitan mungkin memberi kesan kepada perkhidmatan lain. Dalam kes ini, penyiaran kesalahan standard dan saluran komunikasi boleh pergi jauh. Saya telah menemui beberapa mesej amaran yang jarang berlaku - dan menyedari bahawa orang dalam pasukan lain melihat fenomena aneh yang serupa. Dengan menyertai kumpulan sembang terpusat untuk mengendalikan gangguan, kami dengan cepat mengenal pasti perkhidmatan yang menyebabkan gangguan dan menyelesaikan isu tersebut. Kami menyelesaikannya lebih cepat daripada yang boleh dilakukan oleh mana-mana orang.

Legakan sekarang, siasat esok. Semasa kerosakan, saya sering mendapat "tergesa-gesa adrenalin" kerana ingin membetulkan masalah yang berlaku. Selalunya punca utama ialah penggunaan kod yang lemah, dengan pepijat yang jelas dalam perubahan kod. Pada masa lalu, saya akan melompat terus dan membetulkan pepijat, menolak pembetulan dan menutup pepijat dan bukannya memutar balik perubahan kod. Walau bagaimanapun, membetulkan punca semasa kegagalan adalah idea yang mengerikan. Terdapat sedikit keuntungan dan banyak kerugian daripada menggunakan pemulihan hadapan. Oleh kerana pembaikan baharu perlu dilakukan dengan cepat, ia mesti diuji dalam pengeluaran. Inilah sebabnya mengapa ralat kedua - atau ralat di atas ralat sedia ada - diperkenalkan. Saya telah melihat gangguan seperti ini semakin teruk. Hanya fokus pada mitigasi dahulu dan tahan keinginan untuk membetulkan atau menyiasat puncanya. Siasatan yang betul boleh menunggu sehingga hari perniagaan berikutnya.

Nota Penterjemah: Pemandu veteran juga harus menyedari perkara ini dengan mendalam Jangan nyahpepijat dalam talian Jika masalah berlaku, putar semula dengan segera daripada cuba mengeluarkan versi perbaikan terbaru untuk membetulkannya.

Analisis bedah siasat, semakan insiden dan budaya penambahbaikan berterusan

Ini adalah tentang cara pasukan mengendalikan akibat kegagalan. Adakah mereka akan terus bekerja? Adakah mereka akan membuat tinjauan kecil? Adakah mereka akan menghabiskan banyak usaha yang mengejutkan di jalan raya, menghentikan kerja produk untuk membuat pembetulan peringkat sistem?

Bedah siasat yang dilakukan dengan betul adalah asas pembinaan sistem yang kukuh. Postmortem yang baik adalah tidak menuduh dan menyeluruh. Templat bedah siasat Uber terus berkembang dengan teknologi kejuruteraan dan termasuk bahagian seperti gambaran keseluruhan insiden, gambaran keseluruhan kesan, garis masa, analisis punca punca, pengajaran yang dipelajari dan senarai semak susulan terperinci.

Ini ialah templat ulasan yang serupa dengan yang saya gunakan di Uber.

Bedah siasat yang baik menggali punca dan mencadangkan penambahbaikan untuk mencegah, mengesan atau mengurangkan semua kegagalan yang serupa dengan lebih cepat. Apabila saya katakan gali lebih dalam, maksud saya mereka tidak berhenti pada punca utama, iaitu perubahan kod yang salah dan penyemak kod tidak menangkap pepijat.

Mereka menggunakan kaedah penerokaan “5why” untuk menggali lebih mendalam bagi mencapai kesimpulan yang lebih bermakna. Contohnya:

• Mengapa masalah ini berlaku? –> Kerana pepijat telah dimasukkan ke dalam kod.
• Mengapa tidak ada orang lain yang menangkap pepijat ini? –> Perubahan kod yang tidak disedari oleh penyemak kod boleh menyebabkan masalah sedemikian.
• Mengapa kami hanya bergantung pada penyemak kod untuk menangkap ralat ini? –> Kerana kami tidak mempunyai ujian automatik untuk kes penggunaan ini.
• “Mengapa kami tidak mempunyai ujian automatik untuk kes penggunaan ini?” –>
• Mengapa kami tidak mempunyai akaun ujian? –> Kerana sistem belum menyokongnya
• Kesimpulan: Isu ini menunjukkan isu sistemik dengan kekurangan akaun ujian. Adalah disyorkan bahawa sokongan akaun ujian ditambahkan pada sistem. Seterusnya, tulis ujian automatik untuk semua perubahan kod serupa pada masa hadapan.

Semakan acara ialah alat sokongan penting untuk analisis selepas acara. Walaupun banyak pasukan teliti dalam analisis bedah siasat mereka, yang lain boleh mendapat manfaat daripada input dan cabaran tambahan untuk penambahbaikan pencegahan. Ia juga penting bahawa pasukan berasa bertanggungjawab dan diberi kuasa untuk melaksanakan penambahbaikan peringkat sistem yang mereka cadangkan.

Bagi organisasi yang mengambil berat tentang kebolehpercayaan, kegagalan yang paling serius disemak dan dicabar oleh jurutera berpengalaman. Pengurusan kejuruteraan di peringkat organisasi juga harus hadir untuk memberikan kuasa untuk menyelesaikan pembaikan—terutamanya jika pembaikan ini memakan masa dan menghalang kerja lain. Sistem yang teguh tidak berlaku dalam sekelip mata: ia dibina melalui lelaran berterusan. Bagaimanakah kita boleh terus mengulang? Ini memerlukan budaya penambahbaikan berterusan dan belajar daripada kegagalan di peringkat organisasi.

Latih Tubi Kegagalan, Perancangan Kapasiti dan Ujian Kotak Hitam

Terdapat beberapa aktiviti rutin yang memerlukan pelaburan yang besar tetapi penting untuk memastikan sistem teragih yang besar berfungsi dan berfungsi. Ini adalah konsep yang pertama kali saya dedahkan di Uber—di syarikat terdahulu, kami tidak perlu menggunakannya kerana skala dan infrastruktur kami tidak mendorong kami untuk berbuat demikian.

Latih tubi kegagalan pusat data adalah sesuatu yang saya fikir membosankan sehingga saya memerhatikan beberapa daripadanya sedang beraksi. Pemikiran awal saya ialah mereka bentuk sistem teragih yang teguh adalah tepat untuk dapat kekal berdaya tahan sekiranya pusat data runtuh. Jika ia berfungsi dengan baik dalam teori, mengapa mengujinya dengan kerap? Jawapannya ada kaitan dengan skala dan keperluan untuk menguji sama ada perkhidmatan itu boleh mengendalikan peningkatan trafik yang mendadak di pusat data baharu dengan berkesan.

Senario kegagalan yang paling biasa saya perhatikan ialah apabila failover berlaku dan perkhidmatan dalam pusat data baharu tidak mempunyai sumber yang mencukupi untuk mengendalikan trafik global. Andaikan bahawa ServiceA dan ServiceB dijalankan dari dua pusat data masing-masing. Andaikan penggunaan sumber ialah 60%, dengan berdozen atau ratusan mesin maya berjalan di setiap pusat data, dan tetapkan penggera untuk mencetuskan pada 70%. Sekarang mari kita lakukan failover dan ubah hala semua trafik dari DataCenterA ke DataCenterB. Tanpa memperuntukkan mesin baharu, DataCenterB tiba-tiba tidak dapat mengendalikan beban. Memperuntukkan mesin baharu boleh mengambil masa yang cukup lama sehingga permintaan bertimbun dan mula digugurkan. Penyekatan ini mungkin mula menjejaskan perkhidmatan lain, menyebabkan kegagalan berlatarkan sistem lain yang bukan sebahagian daripada failover ini.

Senario kegagalan biasa yang lain termasuk isu tahap penghalaan, isu kapasiti rangkaian atau titik sakit tekanan belakang. Failover pusat data ialah latihan yang mana-mana sistem teragih yang boleh dipercayai sepatutnya boleh lakukan tanpa sebarang kesan pengguna. Saya menekankan "harus" - latihan ini adalah salah satu latihan yang paling berguna untuk menguji kebolehpercayaan sistem teragih.

Nota Penterjemah: Mengurangkan trafik ialah salah satu daripada "tiga paksi" pelan. Apabila sesuatu berlaku, untuk memastikan rancangan itu tersedia, latihan adalah amat diperlukan. Beri perhatian, kawan-kawan.

Latihan masa henti perkhidmatan yang dirancang ialah cara terbaik untuk menguji daya tahan keseluruhan sistem anda. Ini juga merupakan cara terbaik untuk menemui kebergantungan tersembunyi atau penggunaan sistem tertentu yang tidak sesuai/tidak disengajakan. Walaupun latihan ini agak mudah dicapai untuk perkhidmatan yang menghadapi pelanggan dengan sedikit kebergantungan, ia tidak begitu mudah untuk sistem kritikal yang memerlukan ketersediaan tinggi atau dipercayai oleh banyak sistem lain. Tetapi apa yang berlaku apabila sistem kritikal ini menjadi tidak tersedia satu hari nanti? Adalah lebih baik untuk mengesahkan jawapan melalui latihan terkawal di mana semua pasukan sedar dan bersedia untuk gangguan yang tidak dijangka.

Pengujian kotak hitam ialah kaedah mengukur ketepatan sistem sehampir mungkin dengan keadaan yang dilihat oleh pengguna akhir. Jenis ujian ini serupa dengan ujian hujung ke hujung, tetapi untuk kebanyakan produk, ujian kotak hitam yang betul memerlukan pelaburan yang berasingan. Proses pengguna utama dan senario ujian yang paling biasa dihadapi pengguna ialah contoh kebolehujian kotak hitam yang baik: sediakan dalam cara yang boleh dicetuskan pada bila-bila masa untuk memastikan sistem berfungsi dengan betul.

Mengambil Uber sebagai contoh, ujian kotak hitam yang jelas adalah untuk memeriksa sama ada proses pemandu penumpang berfungsi dengan baik di peringkat bandar. Iaitu, bolehkah penumpang dalam bandar tertentu meminta Uber, bekerjasama dengan pemandu dan menyelesaikan perjalanan? Setelah keadaan ini diautomatikkan, ujian ini boleh dijalankan secara berkala, mensimulasikan bandar yang berbeza. Mempunyai sistem ujian kotak hitam yang berkuasa memudahkan untuk mengesahkan bahawa sistem atau sebahagian daripada sistem berfungsi dengan betul. Ia juga sangat membantu untuk latihan failover: cara terpantas untuk mendapatkan maklum balas failover adalah dengan menjalankan ujian kotak hitam.

Gambar di atas ialah contoh menggunakan ujian kotak hitam apabila gerudi failover gagal, dan digulung semula secara manual selepas beberapa minit gerudi.

Perancangan kapasiti adalah sama penting untuk sistem teragih yang besar. Secara umumnya, saya maksudkan kos pengkomputeran dan penyimpanan mencecah puluhan atau ratusan ribu ringgit sebulan. Pada skala ini, menggunakan bilangan penempatan tetap mungkin lebih murah daripada menggunakan penyelesaian awan penskalaan automatik. Sekurang-kurangnya, penempatan tetap harus mengendalikan trafik "perniagaan seperti biasa" dan berskala secara automatik semasa beban puncak. Tetapi berapa banyak contoh minimum yang anda perlu jalankan pada bulan depan, tiga bulan berikutnya dan tahun depan?

Meramalkan corak trafik masa hadapan untuk sistem matang dengan data sejarah yang baik bukanlah sukar. Ini penting untuk belanjawan, memilih vendor atau mengunci diskaun penyedia awan. Jika perkhidmatan anda mahal dan anda tidak memikirkan tentang perancangan kapasiti, anda kehilangan cara mudah untuk mengurangkan dan mengawal kos.

SLO, SLA dan laporan berkaitan

SLO bermaksud Objektif Tahap Perkhidmatan - sasaran berangka untuk ketersediaan sistem. Amalan yang baik untuk menentukan SLO tahap perkhidmatan (seperti sasaran untuk kapasiti, kependaman, ketepatan dan ketersediaan) untuk setiap perkhidmatan individu. SLO ini kemudiannya boleh berfungsi sebagai pencetus untuk makluman. Contoh tahap perkhidmatan SLO mungkin kelihatan seperti ini:

Metrik SLO	Subkategori	Nilai untuk Perkhidmatan
Kapasiti	Keupayaan minimum	500 req/saat
Latensi		Masa tindak balas median yang dijangkakan	50-90ms
	Dijangka masa tindak balas p99	500-800ms
Ketepatan	Kadar ralat maksimum	0.5%
Ketersediaan	Waktu beroperasi terjamin	99.9%

SLO peringkat perniagaan atau SLO berfungsi ialah abstraksi di atas perkhidmatan. Mereka akan meliputi metrik berorientasikan pengguna atau perniagaan. Sebagai contoh, SLO peringkat perniagaan mungkin kelihatan seperti ini: Jangkakan 99.99% resit e-mel dihantar dalam masa 1 minit selepas perjalanan selesai. SLO ini mungkin dipetakan kepada SLO peringkat perkhidmatan (seperti kependaman untuk sistem pembayaran dan penerimaan e-mel), atau ia mungkin perlu diukur secara berbeza.

SLA - Perjanjian Tahap Perkhidmatan - ialah perjanjian yang lebih luas antara penyedia perkhidmatan dan pengguna perkhidmatan. Biasanya, berbilang SLO membentuk SLA. Sebagai contoh, 99.99% sistem pembayaran yang tersedia boleh menjadi SLA yang dipecahkan kepada SLO tertentu untuk setiap sistem sokongan.

Selepas mentakrifkan SLO anda, langkah seterusnya ialah mengukur ini dan melaporkannya. Mengautomasikan pemantauan dan pelaporan mengenai SLA dan SLO selalunya merupakan projek yang kompleks yang kedua-dua pasukan kejuruteraan dan unit perniagaan cenderung untuk mengetepikan keutamaan. Pasukan kejuruteraan mungkin kurang berminat kerana mereka sudah mempunyai pelbagai peringkat pemantauan untuk mengesan kegagalan dalam masa nyata. Unit perniagaan, sebaliknya, lebih suka menumpukan pada penyampaian fungsi daripada melabur dalam projek kompleks yang tidak mempunyai kesan perniagaan segera.

Yang membawa kita ke topik seterusnya: lambat laun, organisasi yang mengendalikan sistem teragih yang besar perlu mendedikasikan kakitangan yang berdedikasi kepada kebolehpercayaan sistem ini. Mari kita bincangkan tentang pasukan kejuruteraan kebolehpercayaan tapak web.

SRE sebagai pasukan bebas

Kejuruteraan Kebolehpercayaan Tapak berasal daripada Google, bermula sekitar tahun 2003 dan kini telah berkembang menjadi pasukan yang terdiri daripada lebih 1,500 jurutera SRE. Memandangkan operasi persekitaran pengeluaran menjadi lebih kompleks dan memerlukan lebih banyak automasi, kerja ini boleh menjadi pekerjaan sepenuh masa dengan cepat. Masa yang diambil oleh syarikat untuk menyedari bahawa mereka mempunyai jurutera yang bekerja sepenuh masa dalam automasi pengeluaran berbeza-beza: semakin kritikal dan terdedah kepada kerosakan sistem ini, semakin awal ini berlaku.

Syarikat teknologi yang berkembang pesat sering membentuk pasukan SRE lebih awal dan membiarkan mereka membangunkan peta jalan mereka sendiri. Di Uber, pasukan SRE telah diasaskan pada 2015 dengan misi mengurus kerumitan sistem dari semasa ke semasa. Syarikat lain mungkin melancarkan pasukan sedemikian pada masa yang sama semasa mereka mencipta pasukan infrastruktur yang berdedikasi. Apabila syarikat berkembang ke tahap di mana kerja kebolehpercayaan merentas pasukan mengambil banyak masa jurutera, sudah tiba masanya untuk mencipta pasukan khusus untuknya.

Mempunyai pasukan SRE memudahkan semua jurutera mengekalkan aspek operasi sistem teragih yang besar. Pasukan SRE mungkin mempunyai alat pemantauan dan amaran standard. Mereka mungkin membeli atau membina alat oncall dan menjadi pasukan goto untuk amalan terbaik oncall. Mereka mungkin memudahkan semakan kegagalan dan membina sistem untuk lebih mudah mengesan, mengurangkan dan mencegah kegagalan. Mereka pastinya membantu dengan latihan failover, sering memudahkan ujian kotak hitam, dan mengambil bahagian dalam perancangan kapasiti. Mereka mendorong pemilihan, penyesuaian atau pembinaan alat standard untuk mentakrif dan mengukur SLO serta melaporkannya.

Memandangkan syarikat mempunyai titik kesakitan yang berbeza yang mereka lihat kepada SRE untuk diselesaikan, organisasi SRE berbeza antara syarikat. Nama pasukan ini selalunya berbeza-beza: ia mungkin dipanggil Operasi, Kejuruteraan Platform atau Infrastruktur. Google telah menerbitkan dua buku yang mesti dibaca tentang kebolehpercayaan tapak yang tersedia secara percuma dan merupakan cara terbaik untuk mengetahui lebih lanjut tentang SRE.

Kebolehpercayaan sebagai pelaburan berterusan

Apabila membina sebarang produk, membina versi pertama hanyalah permulaan. Selepas v1, ciri baharu akan ditambah dalam lelaran akan datang. Jika produk berjaya dan memberikan hasil perniagaan, kerja diteruskan.

Sistem teragih mempunyai kitaran hayat yang serupa, cuma ia memerlukan lebih banyak pelaburan, bukan sahaja untuk ciri baharu, tetapi juga untuk mengikuti perkembangan. Apabila sistem mula mengambil lebih banyak beban, menyimpan lebih banyak data, dan mempunyai lebih ramai jurutera yang bekerja padanya, ia memerlukan perhatian berterusan untuk terus berjalan dengan lancar. Ramai orang apabila membina sistem teragih buat kali pertama menganggap sistem itu seperti sebuah kereta: setelah dibina, ia hanya memerlukan penyelenggaraan yang diperlukan setiap beberapa bulan. Tetapi perbandingan ini jauh dari realiti.

Saya suka membandingkan usaha mengendalikan sistem teragih dengan menjalankan organisasi besar, seperti hospital. Untuk memastikan hospital berfungsi dengan baik, pengesahan dan pemeriksaan berterusan (pemantauan, penggera, ujian kotak hitam) diperlukan. Kakitangan dan peralatan baharu sentiasa ditambah: untuk hospital, ini adalah kakitangan seperti jururawat dan doktor dan peralatan perubatan baharu untuk sistem yang diedarkan, ia sedang merekrut jurutera baharu dan menambah perkhidmatan baharu; Apabila bilangan orang dan perkhidmatan bertambah, cara lama melakukan sesuatu menjadi tidak cekap: sama seperti klinik desa kecil berbeza daripada hospital besar di kawasan metropolitan. Menghasilkan cara yang lebih cekap menjadi kerja sepenuh masa, dan mengukur serta melaporkan kecekapan menjadi penting. Sama seperti hospital besar yang mempunyai kakitangan pejabat yang bersifat sokongan seperti kewangan, sumber manusia atau keselamatan, menjalankan sistem teragih berskala lebih besar juga bergantung pada pasukan sokongan seperti infrastruktur dan SRE.

Untuk membolehkan pasukan menjalankan sistem edaran yang boleh dipercayai, organisasi perlu terus melabur dalam pengendalian sistem ini dan platform yang dibina di atasnya.

Atas ialah kandungan terperinci Amalan Uber: Beberapa pengalaman dalam mengendalikan dan menyelenggara sistem teragih berskala besar. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!