😡 🛕 👩🏿‍🎤 Mengoperasikan Sistem Terdistribusi Besar: Apa yang Saya Pelajari 👩🏽‍🔬 ◻️ 👨‍🔧

Membaca berbagai saluran dan buletin, saya sering menemukan artikel tentang "rasa sakit" spesifik dan masalah yang muncul ketika perusahaan tumbuh, ketika keandalan dan skalabilitas muncul. Artikel ini berbeda. Tidak ada analisis rinci tentang solusi arsitektur tertentu atau panduan langkah demi langkah untuk mengubah budaya rekayasa. Sebaliknya, ini adalah pandangan teratas dari tantangan yang muncul saat mengoperasikan sistem terdistribusi, dan titik awal yang akan membantu Anda menavigasi aliran istilah, singkatan, dan teknologi.

Saya membawa kepada Anda terjemahan dari artikel yang ditulis oleh seorang insinyur dari Uber.

* * *

Dalam beberapa tahun terakhir, saya telah membuat dan memelihara sistem pembayaran terdistribusi besar di Uber . Selama waktu ini, saya belajar banyak tentang konsep arsitektur terdistribusi.dan dari pengalaman saya sendiri, saya menemukan betapa sulitnya membuat dan memelihara sistem yang sarat muatan dengan ketersediaan tinggi. Membangun sistem seperti itu adalah pekerjaan yang menarik. Saya suka merencanakan bagaimana sistem akan menangani pertumbuhan lalu lintas 10-100 kali, untuk memastikan keandalan data terlepas dari kegagalan perangkat keras. Namun, mengoperasikan sistem terdistribusi besar memberi saya pengalaman yang tidak terduga .

Semakin besar sistem, semakin besar kemungkinan Anda akan menemukan manifestasi hukum Murphy: " Segala sesuatu yang bisa salah akan salah ." Kemungkinannya sangat tinggi dengan rilis yang sering, ketika banyak pengembang mengeluarkan kode, ketika menggunakan beberapa pusat data dan dengan audiens yang besar dari pengguna di seluruh dunia. Selama beberapa tahun terakhir, saya telah menemukan berbagai crash sistem, banyak di antaranya mengejutkan saya: dari masalah yang dapat diprediksi, seperti crash perangkat keras atau bug yang tidak bersalah, hingga kabel putus yang menghubungkan pusat data ke banyak crash berjenjang yang terjadi secara bersamaan. Saya mengalami banyak kegagalan di mana bagian-bagian dari sistem tidak bekerja dengan benar, yang sangat memengaruhi bisnis.

Artikel ini merangkum teknik yang mendapat manfaat dari pengoperasian sistem besar di Uber. Pengalaman saya tidak unik: orang lain bekerja dengan sistem dengan ukuran yang sama dan menjalani petualangan yang sama. Saya berbicara dengan para insinyur dari Google, Facebook dan Netflix, yang menghadapi situasi serupa dan menghasilkan solusi serupa. Banyak ide dan proses yang dijelaskan di sini dapat diterapkan pada sistem dengan skala yang sama, terlepas dari apakah mereka bekerja di pusat data milik perusahaan (seperti yang paling sering terjadi dengan Uber) atau di cloud (di mana Uber terkadang berskala ). Namun, tips ini mungkin berlebihan untuk sistem yang tidak terlalu besar atau penting bagi perusahaan.

Kami akan berbicara tentang topik-topik tersebut:

Pemantauan
Duty (on-call), deteksi dan notifikasi anomali.
Kegagalan dan manajemen insiden.
Post Mortem, analisis insiden dan budaya perbaikan berkelanjutan.
Kegagalan, perencanaan sumber daya, dan pengujian kotak hitam.
SLO, SLA dan melaporkannya.
SRE sebagai tim independen.
Keandalan sebagai investasi permanen.
Bahan yang berguna.

Pemantauan

Untuk memahami apakah sistem itu sehat, kita perlu menjawab pertanyaan: “Apakah itu bekerja dengan benar? ". Untuk ini, penting untuk mengumpulkan informasi tentang bagian-bagian penting dari sistem. Dan ketika Anda memiliki sistem terdistribusi yang terdiri dari berbagai layanan di berbagai server dan di pusat data yang berbeda, mungkin sulit untuk menentukan titik kunci mana yang benar - benar perlu Anda lacak.

Memantau status infrastruktur.Jika satu atau lebih mesin / mesin virtual kelebihan beban, maka beberapa bagian dari sistem terdistribusi dapat menurunkan kinerja. Metrik keadaan mesin tempat layanan dijalankan - konsumsi sumber daya prosesor dan memori - ini adalah parameter dasar yang perlu dipantau. Ada platform yang awalnya melacak metrik ini dan secara otomatis mengukur instance. Uber memiliki tim infrastruktur inti yang hebat , yang secara default menyediakan pemantauan dan peringatan. Terlepas dari metode implementasi, Anda harus memiliki informasi bahwa instans, infrastruktur, atau layanan individual memiliki masalah.

Pemantauan status layanan: lalu lintas, kesalahan, keterlambatan . Seringkali Anda perlu memiliki jawaban untuk pertanyaan "Apakah backend berfungsi dengan baik? ". Memantau metrik seperti jumlah lalu lintas yang masuk, proporsi kesalahan dan keterlambatan dalam respons memberikan informasi berharga tentang status layanan. Saya lebih suka membuat dasbor untuk semua metrik ini. Saat Anda membuat layanan baru, menggunakan respons HTTP yang benar dan memantau kode yang sesuai dapat memberi tahu banyak tentang kondisi sistem. Jika Anda yakin bahwa kode 4xx dikembalikan untuk kesalahan klien, dan kode 5xx dikembalikan untuk kesalahan server, maka akan mudah bagi Anda untuk membuat dan menafsirkan pemantauan tersebut.

Ada hal lain yang bisa dikatakan tentang keterlambatan pemantauan respons. Tujuan dari layanan produksi adalah agar sebagian besar pengguna akhir dapat menikmati menggunakannya. Dan mengukur keterlambatan rata-rata bukanlah solusi terbaik, karena nilai rata-rata dapat menyembunyikan sejumlah kecil permintaan dengan penundaan besar. Adalah jauh lebih baik untuk mengukur p95, p99 atau p999 - penundaan untuk persentil ke-95, ke-99 atau ke-99,9 dari permintaan. Angka-angka ini membantu menjawab pertanyaan seperti, " Seberapa cepat permintaan akan untuk 99% pengunjung?" "(P99) atau" Seberapa lambat permintaan untuk satu pengunjung dari 1000? "(P999). Jika Anda tertarik dengan detailnya, maka Anda dapat membaca artikel ini .

Grafik untuk p95 dan p99. Perhatikan bahwa penundaan rata-rata untuk titik akhir ini kurang dari 1 detik, dan 1% dari permintaan membutuhkan waktu 2 detik. dan banyak lagi - ini tidak terlihat saat mengukur nilai rata-rata.

Topik pemantauan dan observabilitas jauh lebih dalam. Saya merekomendasikan membaca buku SRE Google dan bagian Empat sinyal emas pada pemantauan sistem terdistribusi. Jika untuk sistem yang berinteraksi dengan pengguna, Anda hanya bisa mendapatkan empat metrik, lalu fokus pada lalu lintas, kesalahan, tunda dan saturasi. Ada sedikit bahan - e-book Sistem Terdistribusi yang Diamati , yang menjelaskan alat yang bermanfaat seperti log, serta praktik terbaik untuk menggunakan metrik dan penelusuran.

Memantau metrik bisnis. Layanan pemantauan memberi tahu kami tentang kondisi mereka secara keseluruhan. Tetapi menurut pemantauan data saja, kita tidak bisa mengatakan apakah layanan berfungsi dengan baik, apakah semuanya diproses dengan benar dari sudut pandang bisnis. Dalam hal sistem pembayaran, pertanyaan utamanya adalah: “ Bisakah orang melakukan perjalanan menggunakan metode pembayaran tertentu? ". Salah satu langkah paling penting dalam pemantauan adalah mengidentifikasi dan melacak peristiwa bisnis yang dibuat dan diproses oleh layanan ini.

Tim saya membuat pemantauan metrik bisnis setelah kegagalan yang tidak dapat kami deteksi dengan cara lain. Semuanya tampak seolah-olah layanan berfungsi normal, tetapi sebenarnya fungsi utama tidak berfungsi. Jenis pemantauan ini sangat tidak lazim bagi perusahaan dan bidang kegiatan kami. Karena itu, kami harus melakukan banyak upaya untuk mengkonfigurasi pemantauan ini untuk diri kami sendiri , menciptakan sistem kami sendiri .

Tugas, Deteksi Anomali, dan Peringatan

Pemantauan adalah alat yang hebat untuk memeriksa status sistem saat ini. Tapi ini hanya langkah di jalan untuk secara otomatis mendeteksi kegagalan dan mengingatkan mereka yang harus melakukan sesuatu dalam kasus ini.

Menonton adalah topik yang luas. Majalah Increment melakukan pekerjaan yang sangat baik dengan menyoroti banyak masalah dalam masalah On-Call . Menurut pendapat saya, tugas adalah kelanjutan logis dari pendekatan "yang Anda buat - Anda miliki". Layanan tersebut dimiliki oleh tim yang membuatnya, dan mereka juga memiliki sistem respons siaga dan insiden. Tim saya memiliki sistem untuk layanan pembayaran yang kami buat. Dan ketika peringatan tiba, insinyur yang bertugas harus merespons dan mencari tahu apa yang terjadi. Tetapi bagaimana kita beralih dari pemantauan ke peringatan?

Menentukan anomali berdasarkan pemantauan data adalah tugas yang sulit , dan pembelajaran mesin harus sepenuhnya memanifestasikan dirinya di sini. Ada banyak layanan pihak ketiga untuk mendeteksi anomali. Untungnya bagi tim saya, perusahaan kami memiliki grup pembelajaran mesin sendiri untuk menyelesaikan masalah yang dihadapi Uber. Tim New York menulis artikel yang bermanfaat tentang bagaimana deteksi Uber terhadap anomali bekerja . Dari sudut pandang tim saya, kami hanya mengirimkan data pemantauan ke saluran ini dan menerima peringatan dengan berbagai tingkat kepercayaan. Dan kemudian kami memutuskan apakah akan memberi tahu insinyur tentang hal itu.

Kapan saya perlu mengirim peringatan? Pertanyaannya menarik. Jika terlalu sedikit lansiran, maka kami mungkin melewatkan kesalahan penting. Jika terlalu banyak, maka orang tidak akan tidur di malam hari.Melacak dan mengelompokkan peringatan, serta mengukur rasio sinyal-ke-suara, memainkan peran besar dalam menyiapkan sistem peringatan . Langkah yang baik menuju rotasi yang stabil dari para insinyur tugas adalah menganalisis peringatan, mengategorikan peristiwa sebagai “membutuhkan tindakan” dan “tidak membutuhkan”, dan kemudian mengurangi jumlah peringatan yang tidak memerlukan tindakan.

Contoh panel Tugas Panggil yang dibuat oleh tim Pengalaman Pengembang Uber di Vilnius.

Tim Uber untuk membuat alat pengembangan dari Vilnius telah menciptakan alat kecil yang kami gunakan untuk mengomentari peringatan dan memvisualisasikan perubahan tugas. Tim kami menghasilkan laporan mingguan tentang pekerjaan shift terakhir yang bertugas, menganalisis kelemahan, dan meningkatkan metodologi tugas.

Kegagalan dan manajemen insiden

Bayangkan: Anda adalah seorang insinyur tugas selama seminggu. Di tengah malam Anda bangun pesan di pager. Anda memeriksa apakah ada kegagalan produksi. Sial, sepertinya bagian dari sistem telah crash. Sekarang apa? Pemantauan dan peringatan hanya berfungsi.

Kegagalan mungkin tidak terlalu bermasalah untuk sistem kecil ketika insinyur yang bertugas dapat memahami apa yang terjadi dan mengapa. Biasanya dalam sistem seperti itu, Anda dapat dengan cepat mengidentifikasi penyebab dan menyingkirkannya. Tetapi dalam kasus sistem kompleks yang mengandung banyak layanan (mikro), ketika banyak insinyur mengirim kode ke dalam operasi, alasan kegagalan agak sulit. Dan kepatuhan terhadap beberapa prosedur standar dapat sangat membantu.

Garis pertahanan pertama adalah buku pedoman prosedur respons standaryang menjelaskan langkah pemecahan masalah sederhana. Jika perusahaan memiliki daftar seperti itu dan didukung secara aktif, maka ide dangkal dari insinyur tugas tentang sistem tidak mungkin menjadi masalah. Daftar tersebut harus selalu diperbarui, diperbarui dan diproses dengan cara-cara baru untuk menyelesaikan masalah.

Menginformasikan tentang kegagalan karyawan lainMenjadi sangat penting jika beberapa tim terlibat dalam meluncurkan layanan. Di lingkungan tempat saya bekerja, layanan, sesuai kebutuhan, diluncurkan oleh ribuan insinyur, dengan frekuensi ratusan kali per jam. Dan peluncuran layanan yang tampaknya tidak berbahaya dapat mempengaruhi layanan lainnya. Dalam situasi seperti itu, peran penting dimainkan oleh standardisasi pelaporan kesalahan dan saluran komunikasi. Saya memiliki banyak kasus ketika peringatan tidak seperti yang lain, dan saya menyadari bahwa untuk tim lain ini juga terlihat aneh. Berkomunikasi dalam obrolan umum tentang kegagalan, kami mengidentifikasi layanan yang bertanggung jawab atas kegagalan dan dengan cepat menghilangkan konsekuensinya. Bersama-sama kita berhasil melakukan ini lebih cepat daripada kita masing-masing.

Hilangkan konsekuensinya sekarang, dan cari tahu besok. Di tengah kecelakaan, saya sering diliputi gelombang adrenalin karena keinginan untuk memperbaiki kesalahan. Seringkali penyebab masalah adalah meluncurkan kode buruk dengan bug yang jelas. Sebelumnya, saya akan berhenti semuanya dan mulai memperbaiki kesalahan, mengirim perbaikan dan memutar kembali kode yang gagal. Tetapi memperbaiki penyebab di tengah kecelakaan adalah ide yang mengerikan . Dengan perbaikan cepat, Anda dapat mencapai sedikit dan banyak kehilangan . Karena perbaikan harus dilakukan dengan cepat, itu harus diuji dalam pertempuran. Dan ini adalah jalan menuju bug baru - atau kegagalan baru - di atas yang sudah ada. Saya melihat bagaimana ini menyebabkan sejumlah kegagalan. Fokus saja pada memperbaiki konsekuensinya, jangan tergoda untuk memperbaiki kode atau menemukan penyebabnya. Investigasi akan menunggu sampai besok.

Post Mortem, analisis insiden dan budaya perbaikan berkelanjutan

Laporan kejadian adalah karakteristik penting tentang bagaimana tim mengatasi konsekuensi dari kegagalan. Apakah situasinya membuat orang khawatir? Apakah mereka melakukan sedikit riset, atau menghabiskan banyak upaya untuk mengamati, menghentikan produk, dan melakukan koreksi?

Post-mortem yang ditulis dengan benar adalah salah satu elemen utama membangun sistem yang berkelanjutan. Itu tidak mengutuk siapa pun dan tidak mencari pelakunya, ini adalah studi yang bijaksana dan analisis insiden. Seiring waktu, template kami untuk laporan tersebut berkembang, bagian dengan kesimpulan akhir, penilaian dampak, kronologi peristiwa, analisis alasan utama, pelajaran yang dipetik dan daftar elemen yang terperinci untuk pengamatan lebih lanjut muncul.

Saya menggunakan pola penanganan kesalahan ini di Uber.

Dalam post-mortem yang baik, penyebab kegagalan diselidiki secara menyeluruh dan langkah-langkah diusulkan untuk mencegah, mendeteksi atau dengan cepat menghilangkan konsekuensi dari kegagalan yang serupa. Dan ketika saya mengatakan "dalam-dalam", maksud saya bahwa penulis tidak berhenti pada fakta bahwa alasannya adalah bergulirnya kode dengan bug yang tidak diperhatikan oleh reviewer. Penulis harus menerapkan metodologi Lima Mengapa untuk sampai pada kesimpulan yang lebih bermanfaat. Contohnya:

Mengapa ada masalah? -> Bug telah diunggah sebagai bagian dari kode.
Mengapa tidak ada yang menangkap bug? -> Orang yang melakukan peninjauan tidak memperhatikan bahwa mengubah kode dapat menyebabkan masalah seperti itu.
, ? --> .
? --> .
? --> .
: . , .

Analisis insiden adalah alat pendamping penting untuk mengatasi bug. Sementara beberapa tim bekerja dengan hati-hati pada bug, yang lain mungkin mendapat manfaat dari data tambahan dan melakukan perbaikan pencegahan. Penting juga bahwa tim menganggap diri mereka bertanggung jawab dan mampu melakukan perbaikan yang mereka usulkan di tingkat sistem.

Dalam organisasi yang serius tentang keandalan, insiden paling serius dianalisis dan dihilangkan oleh insinyur yang berpengalaman. Juga diperlukan untuk mengelola teknik di tingkat perusahaan untuk memastikan bahwa koreksi dapat dilakukan - terutama jika mereka memakan waktu atau mengganggu pekerjaan lain. Sistem yang andal tidak dapat dibuat dalam satu malam: iterasi konstan akan diperlukan. Iterasi yang dihasilkan dari budaya perusahaan perbaikan berkelanjutan berdasarkan pelajaran dari insiden.

Kegagalan, perencanaan sumber daya, dan pengujian kotak hitam

Ada beberapa prosedur reguler yang membutuhkan investasi besar, tetapi sangat penting untuk mempertahankan sistem terdistribusi besar. Saya pertama kali menemukan ide-ide ini di Uber, saya tidak perlu menerapkannya pada perusahaan lain karena skala yang lebih kecil dan tidak tersedianya infrastruktur. Saya menganggap

failover bodoh di pusat data (failover) sampai saya menemukan ini sendiri. Awalnya, saya percaya bahwa desain sistem terdistribusi yang stabil adalah stabilitas pusat data yang jatuh. Mengapa harus diuji secara teratur jika semuanya secara teoritis bekerja? Jawabannya tergantung pada penskalaan dan pengujian kemampuan layanan untuk secara efisien menangani peningkatan lalu lintas yang tidak terduga di pusat data baru.

Skenario kegagalan paling umum yang saya temui adalah bahwa layanan ini tidak memiliki sumber daya yang cukup di pusat data baru untuk menangani lalu lintas global jika terjadi kegagalan. Misalkan, layanan A bekerja di satu pusat data dan layanan B di yang lain. Biarkan konsumsi sumber daya menjadi 60% - puluhan atau ratusan mesin virtual berputar di setiap pusat data, dan peringatan dipicu ketika ambang batas 70% tercapai. Semua lalu lintas dari pusat data A ke pusat data B gagal. Pusat data kedua tidak dapat mengatasi peningkatan beban tanpa menggunakan mesin baru. Namun, ini bisa memakan banyak waktu, jadi permintaan mulai menumpuk dan turun. Pemblokiran mulai memengaruhi layanan lain, menyebabkan kegagalan kaskade sistem lain yang tidak terkait dengan kegagalan primer.

Suatu situasi yang memungkinkan di mana kegagalan menyebabkan masalah.

Skenario kegagalan populer lainnya melibatkan masalah di tingkat routing, masalah dengan bandwidth jaringan atau tekanan balik . Kegagalan pusat data adalah pengembangan yang harus dilakukan oleh setiap sistem terdistribusi yang andal tanpa berdampak pada pengguna. Saya menekankan - seharusnya , pengembangan ini adalah salah satu latihan yang paling berguna untuk memeriksa keandalan sistem web terdistribusi.

Latihan penghentian layanan terjadwalCara yang bagus untuk menguji stabilitas seluruh sistem. Ini juga merupakan alat yang hebat untuk mendeteksi dependensi tersembunyi atau penggunaan yang tidak tepat / tidak terduga dari sistem tertentu. Latihan downtime terjadwal dapat relatif mudah dilakukan dengan layanan yang berinteraksi dengan klien dan memiliki sedikit ketergantungan yang diketahui. Namun, jika kita berbicara tentang sistem kritis yang waktu penghentiannya sangat singkat atau bergantung pada banyak sistem lain, maka akan sulit untuk melakukan latihan seperti itu. Tetapi apa yang terjadi jika suatu hari sistem seperti itu tidak tersedia? Lebih baik menjawab pertanyaan ini dalam percobaan terkontrol sehingga semua tim diperingatkan dan siap.

Pengujian blackbox(metode "kotak hitam") adalah cara menilai kebenaran sistem dalam situasi sedekat mungkin dengan bagaimana interaksi dengan pengguna akhir berjalan. Ini mirip dengan pengujian ujung ke ujung, kecuali untuk kenyataan bahwa untuk sebagian besar produk pengujian kotak hitam yang benar memerlukan investasi Anda sendiri. Kandidat yang baik untuk pengujian tersebut adalah proses dan skenario pengguna utama yang melibatkan interaksi pengguna: untuk menguji sistem, pastikan bahwa mereka dapat diluncurkan kapan saja.

Menggunakan Uber sebagai contoh, tes blackbox yang jelas memeriksa interaksi pengemudi-penumpang di tingkat kota: dapatkah penumpang menemukan pengemudi dan melakukan perjalanan berdasarkan permintaan tertentu? Setelah mengotomatisasi skenario ini, tes dapat dijalankan secara teratur, meniru kota yang berbeda. Sistem pengujian blackbox yang andal membuatnya mudah untuk memverifikasi operasi sistem yang benar atau bagian-bagiannya. Ini juga banyak membantu dengan pengujian kegagalan: cara tercepat untuk mendapatkan umpan balik beralih adalah dengan menjalankan pengujian kotak hitam.

Contoh pengujian blackbox selama failover failover dan rollback manual.

Perencanaan sumber dayamemainkan peran yang sangat penting untuk sistem terdistribusi besar. Secara umum, yang saya maksudkan adalah biaya komputasi dan penyimpanan dihitung dalam puluhan atau ratusan ribu dolar per bulan. Pada skala ini, mungkin lebih murah untuk memiliki jumlah penyebaran yang tetap daripada menggunakan solusi cloud yang dapat diskalakan sendiri. Dalam kasus ekstrem, penerapan tetap harus menangani lalu lintas yang merupakan karakteristik "bisnis normal", dengan penskalaan otomatis hanya pada beban puncak. Tetapi berapa jumlah minimum contoh yang diterapkan bulan depan? Dalam tiga bulan ke depan? Tahun depan?

Tidak sulit untuk memprediksi pola lalu lintas masa depan untuk sistem yang matang dengan volume statistik yang besar. Ini penting untuk anggaran, pilihan vendor atau untuk menetapkan diskon dari penyedia cloud. Jika layanan Anda menghasilkan akun besar dan Anda belum memikirkan perencanaan sumber daya, maka Anda kehilangan cara mudah untuk mengurangi biaya dan mengelolanya.

SLO, SLA dan melaporkannya

SLO adalah singkatan dari Service Level Objective , metrik untuk ketersediaan sistem. Ini adalah praktik yang baik untuk menetapkan SLO di tingkat layanan untuk kinerja, waktu respons, kebenaran, dan ketersediaan. SLO ini kemudian dapat digunakan sebagai ambang waspada. Contoh:

Metrik SLO	Subkategori	Nilai Layanan
Performa	Bandwidth minimum	500 permintaan per detik
		2 500
		50-90
	p99	500-800
		0,5 %
		99,9 %

SLO di tingkat bisnis . atau SLO fungsional, ini adalah abstraksi atas layanan. Itu mencakup metrik khusus atau bisnis. Misalnya, SLO di tingkat bisnis mungkin adalah ini: 99,99% dari penerimaan diharapkan akan dikirim dalam waktu 1 menit setelah menyelesaikan perjalanan. SLO ini dapat dibandingkan dengan SLO di tingkat layanan (misalnya, dengan keterlambatan sistem pembayaran atau sistem pengiriman cek surat), dan dapat diukur secara terpisah.

SLA - Perjanjian Tingkat Layanan . Ini adalah perjanjian yang lebih umum antara penyedia layanan dan konsumennya. Biasanya, beberapa SLO membentuk SLA. Misalnya, ketersediaan sistem pembayaran pada tingkat 99,99% mungkin SLA, yang dibagi menjadi SLO tertentu untuk setiap sistem yang sesuai.

Setelah menentukan SLO, Anda perlu mengukurnya dan membuat laporan.Pemantauan dan pelaporan otomatis pada SLA dan SLO seringkali merupakan proyek kompleks yang tidak diprioritaskan oleh insinyur maupun bisnis. Insinyur tidak akan tertarik, karena mereka sudah memiliki level pemantauan yang berbeda untuk mengidentifikasi kegagalan secara real time. Bisnis lebih baik memprioritaskan pengiriman fungsionalitas, daripada berinvestasi dalam proyek yang kompleks yang tidak akan memberikan manfaat langsung.

Dan ini membawa kita ke topik lain: organisasi yang mengoperasikan sistem terdistribusi besar, cepat atau lambat perlu mengalokasikan orang untuk memastikan keandalan sistem ini. Mari kita bicara tentang tim SRE - Rekayasa Keandalan Situs.

SRE sebagai tim independen

Istilah Rekayasa Keandalan Situs ini diciptakan oleh Google sekitar tahun 2003, dan saat ini ada lebih dari 1.500 insinyur SRE. Karena operasi lingkungan produksi menjadi tugas yang semakin kompleks yang membutuhkan otomatisasi lebih banyak, maka akan segera menjadi pekerjaan yang lengkap. Ini terjadi ketika perusahaan menyadari bahwa para insinyur bekerja pada otomatisasi lingkungan produksi hampir sepanjang hari: semakin penting sistem dan semakin banyak kegagalan terjadi, semakin cepat SRE menjadi posisi yang terpisah.

Perusahaan-perusahaan teknologi yang tumbuh cepat seringkali membentuk tim SRE sejak dini, yang mereka rencanakan sendiri. Di Uber, tim semacam itu diciptakan pada tahun 2015.Tujuannya adalah untuk mengelola kompleksitas sistem. Di perusahaan lain, alokasi tim SRE dapat dikaitkan dengan pembentukan tim infrastruktur terpisah. Ketika perusahaan tumbuh ke tingkat yang memastikan keandalan layanan memerlukan perhatian sejumlah besar insinyur, maka sekarang saatnya untuk membuat tim yang terpisah.

Tim SRE sangat menyederhanakan pemeliharaan sistem terdistribusi besar untuk semua insinyur. Tim SRE mungkin memiliki alat pemantauan dan peringatan standar. Mereka mungkin membeli atau membuat alat panggilan dan bersedia untuk berbagi pengalaman mereka. Mereka dapat memfasilitasi analisis insiden dan menciptakan sistem yang membuatnya lebih mudah untuk mendeteksi kegagalan, mengurangi konsekuensinya dan mencegahnya di masa depan. Perintah SRE tentu memfasilitasi operasi failover. Ini sering digunakan untuk menguji kotak hitam dan merencanakan kinerja. Insinyur SRE mengelola pemilihan, penyesuaian, atau pembuatan alat standar untuk menentukan dan mengukur SLO dan melaporkannya.

Mengingat bahwa semua perusahaan memiliki masalah mereka sendiri, untuk solusi yang mereka rekrut SRE, tim tersebut di perusahaan yang berbeda memiliki struktur yang berbeda. Bahkan namanya dapat bervariasi: dapat berupa layanan operasi, rekayasa platform, atau layanan infrastruktur. Google telah menerbitkan dua buku bacaan wajib untuk memastikan keandalan layanan . Mereka tersedia secara bebas dan merupakan sumber informasi yang sangat baik untuk studi yang lebih mendalam tentang topik SRE.

Keandalan sebagai investasi permanen

Saat membuat produk apa pun, merakit versi pertama hanyalah permulaan. Setelah itu akan ada iterasi baru, dengan fitur baru. Jika produk tersebut berhasil dan menguntungkan, maka pekerjaan dilanjutkan.

Sistem terdistribusi memiliki siklus hidup yang sama, kecuali bahwa mereka membutuhkan lebih banyak investasi tidak hanya dalam fitur-fitur baru, tetapi juga dalam menjaga penskalaan. Ketika beban pada sistem meningkat, Anda harus menyimpan lebih banyak data, lebih banyak insinyur mengerjakan sistem, Anda harus terus-menerus menjaga fungsi normalnya. Banyak dari mereka yang membuat sistem terdistribusi untuk pertama kalinya menganggapnya seperti mesin: setelah Anda melakukannya, cukup untuk melakukan pemeliharaan tertentu setiap beberapa bulan. Sulit untuk membuat perbandingan yang lebih jauh dari kenyataan.

, , . Agar rumah sakit dapat bekerja dengan baik, pemeriksaan konstan diperlukan (pemantauan, peringatan, pengujian kotak hitam). Semua waktu yang Anda perlukan untuk mengambil staf dan peralatan baru: untuk rumah sakit, ini adalah perawat, dokter, dan peralatan medis, dan untuk sistem terdistribusi, insinyur dan layanan baru. Dengan meningkatnya jumlah karyawan dan layanan, metode kerja lama menjadi tidak efektif: sebuah klinik kecil di pedesaan bekerja secara berbeda dari rumah sakit besar di kota metropolitan. Mencapai cara fungsi yang lebih efektif berubah menjadi pekerjaan yang lengkap, dan pengukuran dan peringatan menjadi semakin penting. Karena rumah sakit besar membutuhkan lebih banyak staf, seperti akuntansi, sumber daya manusia dan keamanan,dan pengoperasian sistem terdistribusi besar bergantung pada tim layanan seperti infrastruktur dan SRE.

Agar tim dapat mempertahankan sistem terdistribusi yang andal, organisasi harus terus-menerus berinvestasi dalam fungsinya, serta dalam pekerjaan platform di mana sistem dibangun.

Bahan yang berguna

Meskipun artikel ini ternyata panjang, artikel ini hanya menyajikan momen yang paling dangkal. Untuk mempelajari lebih lanjut tentang fitur-fitur sistem operasi terdistribusi, saya merekomendasikan sumber-sumber ini:

Buku

Google SRE Book adalah buku Google gratis yang bagus. Bab Pemantauan Sistem Terdistribusi sangat penting untuk artikel ini .
Sistem Terdistribusi Observability , buku gratis hebat lainnya dengan tips hebat memantau sistem terdistribusi.
Merancang Aplikasi Data-Intensif adalah buku paling praktis tentang konsep sistem terdistribusi yang saya temui. Namun, itu tidak mencakup aspek operasional yang telah kami telaah begitu dalam.

Situs

On-Call Edition dari Increment Magazine : Serangkaian artikel tentang proses respons insiden di Amazon, Dropbox, Facebook, Google, dan Netflix.
Belajar Membangun Sistem Terdistribusi - artikel AWS Engineer yang menjawab pertanyaan "Bagaimana cara belajar membuat sistem terdistribusi besar?"

Lihat komentar pada artikel ini di Hacker News .

Mengoperasikan Sistem Terdistribusi Besar: Apa yang Saya Pelajari