Ada banyak posting tentang seperti apa bentuk wawancara pengkodean di Google. Tapi, sementara tidak dijelaskan dan dibahas secara luas, ada juga cukup sering wawancara desain sistem. Untuk posisi SRE, NALSD: desain sistem besar non-abstrak. Perbedaan utama antara wawancara SWE dan SRE terdiri dari dua surat ini: NA.
Jadi, apa bedanya? Bagaimana bersiap untuk wawancara ini? Mari menjadi non-abstrak, dan gunakan contoh. Untuk menjadi lebih non-abstrak, mari kita ambil sesuatu dari dunia material, sehingga Anda tidak akan diminta hal yang sama persis di wawancara nyata (setidaknya, tidak di wawancara Google) :)
Jadi, mari kita merancang sistem perpustakaan umum. Untuk buku-buku kertas, seperti yang Anda lihat di mana-mana. Seluruh teks di bawah ini ditulis sekaligus dalam waktu sekitar satu jam, untuk secara kasar menunjukkan area yang harus Anda liput / sentuh selama wawancara. Maafkan beberapa gangguan, begitulah menurut saya (karena itu saya).
Wawancara NALSD: desain sistem perpustakaan umum.
Pertama-tama, kami mengumpulkan karakteristik muatan, baik melalui pertanyaan kepada pewawancara, atau dengan membuat perkiraan yang masuk akal (tanpa lupa untuk menyatakannya dengan keras). Karena wawancara berkaitan dengan sistem yang dapat diskalakan, kami mengharapkan kota dengan populasi besar (katakanlah, 1M +). Kami memiliki beberapa opsi: satu gedung besar, atau perpustakaan lokal plus penyimpanan. Saya pikir yang terakhir lebih masuk akal, karena juga memungkinkan kami untuk memperluas sistem ke beberapa kota.
Sekarang mari kita fokus pada sistem untuk kota tunggal; kita harus dapat menerapkan desain yang sama (dengan koreksi kecil) lagi untuk mengembangkannya ke tingkat negara. Jadi, kami memiliki kota dengan populasi 1M +. Untuk mempermudah perhitungan, mari kita bahas kemungkinan 1M pembaca. Setiap pembaca ingin membaca sesuatu secara independen dari setiap pembaca lainnya, pada saat-saat yang tidak pasti. Jadi kita bisa memodelkan aliran pembaca sebagai proses Poisson. Melakukan perhitungan matematika dengan benar agak sulit selama jangka waktu wawancara, jadi mari kita sederhanakan sekali lagi, dan katakan saja sekitar 1% dari kemungkinan pembaca akan datang untuk mengambil buku setiap hari. Jadi anggaplah permintaan 10.000 buku per hari.
Jadi, tugas kita sekarang menjadi: menyediakan kemampuan untuk membagikan 10.000 buku sehari (itu juga berarti, kita harus dapat mengambil kembali 10.000 buku ini suatu hari nanti) di kota 1M +. Perkiraan ini menunjukkan bahwa solusi satu bangunan tidak akan berlaku (untuk menyediakan buku untuk 1 juta + orang, perpustakaan kami harus dapat dijangkau dalam jumlah waktu yang wajar, jika tidak, keinginan mereka untuk mengambil buku akan habis dalam kemacetan lalu lintas). Jadi, mari kita coba tebak ukuran apa yang masuk akal untuk perpustakaan lokal yang harus kita bangun. Perkiraan yang benar-benar benar akan melibatkan kepadatan populasi, latensi pencapaian dll, tetapi karena ini tidak akan mempengaruhi desain keseluruhan, kami dapat kembali membuatnya lebih sederhana dengan mempertimbangkan distribusi seragam dari unit yang sama. Kami masih tidak tahu seberapa besar unitnya, misalnya, kami dapat menyebarkan 10.000 perpustakaan dengan masing-masing 1 buku di seluruh kota, tetapi jelas tidak akan berhasil. Naik satu tingkat lebih rendah.
Satu unit perpustakaan lokal. Agar bermanfaat, mayoritas pengunjung harus dapat menemukan buku yang mereka inginkan. Itu berarti bahwa kita perlu melacak penggunaan dan memperkirakan permintaan untuk permintaan paling populer agar siap melayani mereka. Selain itu, kami harus memiliki berbagai macam barang yang kurang populer. Tebakan kasar saya adalah perpustakaan dengan kurang dari 1000 nama buku, dengan lusinan salinan untuk yang paling populer dan potongan tunggal untuk ekor. Waktu rata-rata untuk membaca buku di perpustakaan kami berkisar dari 3 hari hingga 2 minggu (tentu saja, waktu sebenarnya tergantung pada buku itu sendiri, yang dalam kasus nyata akan memerlukan analisis tambahan); mari kita perkirakan 1 minggu per buku. Itu berarti bahwa sebuah buku yang dibagikan akan kembali dalam 1 minggu, jadi kita harus memiliki persediaan buku-buku terbaik selama 1 minggu (setelah seminggu mereka akan diisi kembali dari pengembalian).
Misalkan faktor ledakan rata-rata 6, yang akan membawa kita ke kapasitas penyimpanan unit 6.000 buku. Penyimpanan yang lebih sedikit berarti kekurangan nama yang paling populer (well, unit yang lebih kecil masih bisa berguna - seperti, Kios Mall kecil dengan "Twilight", tapi mari kita simpan di luar desain kita sekarang)
Dalam kondisi mantap, pengembalian dan pinjaman setiap hari hampir sama (dengan beberapa dispersi), tetapi kami juga harus merencanakan pengembalian puncak (yang bisa berupa acara sinkronisasi eksternal: liburan, tren, dll). Cara yang benar adalah membuat dan menjalankan model statistik. Tapi untuk saat ini, mari kita simpan ⅓ sebagai buffer. Itu berarti bahwa kita harus menyimpan 6000 buku yang siap untuk dibagikan ditambah ruang untuk 2000.
Singkatnya: kita membutuhkan unit perpustakaan dengan 8000 penyimpanan buku. Diperkirakan akan mahal untuk mengisi kembali setiap hari, jadi kita harus berharap ini cukup untuk satu atau dua minggu. Dua minggu, 6000 buku, dengan kemungkinan pengembalian miring, sekitar 300 buku sehari. Untuk hari pembukaan, kami dapat mengisi seluruh penyimpanan (8000 buku) untuk menyemai 2000 buku awal secara bergantian. 2000 dalam 3 hari = 600 buku sehari, dengan penyangga miring = 800 buku sehari.
Mari kita perkirakan throughput dan batasan penyimpanan kita. 1 buku berukuran sekitar 2 cm linier, 8000 buku = 160 meter. Kita bisa melipatnya secara vertikal 4 kali, jadi 40 meter linier. Jika kita membaginya menjadi ~ 5 meter rak, kita akan mendapatkan 8 rak dengan 4 rak, masing-masing panjang 5 meter. Seorang pustakawan (atau robo-pustakawan) harus dapat bekerja dengan dua rak; ekstraksi satu buku akan memakan waktu: 5 detik untuk berjalan ke rak, 5 detik untuk mengambil / meletakkan buku ke tempatnya, 5 detik untuk berjalan kembali (total 15 detik). 4 pustakawan akan memberi kami throughput puncak 15 buku per menit. Dengan demikian, penanganan 900 buku per jam paling banyak.
Jika kami juga memperhitungkan waktu penanganan permintaan (10 detik), waktu pencarian (5 detik), waktu untuk melacak ke dalam sistem (2 detik), kami akan mendapatkan 400 buku / jam puncak. Jadi, kita harus bisa menangani estimasi 800 buku sehari dalam 2 jam.
Mari kita hitung aspek-aspek lain: untuk dapat membagikan 400 buku / jam oleh 4 pustakawan, kita perlu memiliki ruang yang cukup untuk 100 orang yang menunggu dalam antrean, dan pintu masuk harus memungkinkan 400 orang / jam untuk berjalan di kedua arah . Itu berarti bahwa pelambatan utama kami adalah ruang tunggu dan pintu bangunan.
Itu berarti bahwa kita harus dapat menemukan keseimbangan optimal antara ruang penyimpanan dan ruang tunggu selama perhitungan yang tepat untuk desain nyata.
Itu saja untuk level ini, saatnya untuk melanjutkan. Kami memiliki perkiraan permintaan jaringan perpustakaan secara keseluruhan sebanyak 10.000 buku / hari. Satu unit adalah 800 buku / hari, jadi kami membutuhkan 12,5 unit. Jika kita melakukan distribusi geografis yang seragam, setiap pembaca harus berada dalam kisaran 1-2 unit (pada batas kota) dan 3-4 (di dalam kota). Itu akan memberikan kemampuan untuk memuluskan puncak sedikit dan / atau menutupi kekurangan buku-buku top.
Kita juga tahu bahwa setiap perpustakaan dapat ditutup kapan saja (kebakaran, inspeksi, pengecatan pintu lemari es, dll.), Dan semakin banyak unit yang kita miliki, semakin tinggi kemungkinan kebetulan peristiwa-peristiwa ini. Jadi, kita membutuhkan 1 unit redundan untuk setiap 5-6 unit. Jadi, secara total, kami membutuhkan 15 unit untuk memenuhi permintaan kota kami, jika kami akan mempertahankan pasokan yang diperlukan dalam setiap unit.
Seperti yang sudah kita pikirkan sebelumnya, kita perlu mengisi penyimpanan setiap atau dua minggu (sebelumnya kita menebak dua) - sekitar setengah dari penyimpanan harus diganti, untuk mengikuti tren dll. Jadi 4000 buku pengiriman baru dan 4000 buku dihapus dari itu. Di setiap cadangan, kita perlu mengekstrak 4000 buku, dan memasukkan 4000 entri baru kembali. Dengan 400 buku / jam throughput kami, satu persediaan akan menjadi 10 jam yang sangat intens. Yah, sepertinya masih OK, terutama karena operasi massal biasanya lebih murah; tapi bagaimanapun - kita harus ingat bahwa operasi mengisi kembali adalah 5 kali lebih mahal daripada hanya melayani.
Buku rata-rata (2cm * 20cm * 30cm) adalah volume 1,5 liter, jadi 4000 buku = 6 meter kubik. Ini harus masuk ke dalam kendaraan kargo ringan rata-rata tunggal. 1 meter kubik kertas seberat 600kg, 6m ^ 3 = 3,6 ton. Kendaraan kargo ringan rata-rata mampu menangani ~ 1,5 ton, jadi kami membutuhkan 3 di antaranya. Ditambah satu untuk redundansi. Kami memiliki 15 unit perpustakaan yang disegarkan setiap 2 minggu sekali, yang artinya ini sesuai jadwal, jadi kami perlu satu mobil lagi.
Dan kami masih tidak memikirkan bagaimana dan dari mana mobil-mobil ini akan memindahkan buku, jadi desain kami juga akan membutuhkan gudang pemasok dan tempat pengumpulan sampah untuk buku yang tidak lagi populer ...
Waktu sudah habis. Jadi, apa yang istimewa dari pertanyaan NALSD? Skalabilitas diharapkan dari setiap desain sistem besar. Tetapi dalam wawancara NALSD, seseorang harus
spesifik .
Anda dapat melihat banyak dugaan dan asumsi di atas, tetapi semua perhitungan didasarkan pada angka yang dibuat sebelumnya. Saya juga telah mencoba menjelaskan cara mendapatkan nomor yang benar, tetapi mudah lelah / bosan dan mulai hilang untuk melakukannya. Selain itu, mudah untuk tetap menggunakan nomor dari memori Anda, tanpa memberikan penjelasan yang baik tentang alasannya ... Tetapi karena desainnya sangat spesifik, jika Anda membuat kesalahan untuk nomor apa pun, Anda dapat mengubah nomor dan hanya menghitung ulang sisanya.
Saya masih ingat bagaimana selama wawancara NALSD saya, saya terjebak dengan IOPS dari satu HDD sama dengan 600, hanya karena saya baru-baru ini bekerja pada optimasi beberapa raid, di mana seluruh array memiliki 600 IOPS ... Pewawancara sedikit terkejut: 600 IOPS per menyetir? : DSelama wawancara, semua asumsi dan dugaan Anda dapat dikoreksi oleh pewawancara. Juga, pewawancara dapat menambahkan beberapa kendala tambahan (yang Anda lupa, tidak tahu, tidak bertanya atau hanya untuk menyesuaikan tugas karena mereka ingin atau berpikir ini adalah cara yang lebih baik untuk melanjutkan). Karena Anda hanya beroperasi pada angka-angka tertentu, itu hanya akan membutuhkan pembaruan kecil dari angka-angka setelah persamaan yang sudah diberikan.
Jika koreksi asumsi memerlukan desain ulang penuh dari sistem, itu adalah kesalahan desain, atau koreksi yang salah, atau asumsi baru membuat kita melampaui penerapan desain (dan itu tidak begitu jarang dalam kehidupan nyata). Penting untuk tidak melewatkan fakta ini: Anda harus memvalidasi angka yang Anda dapatkan, untuk memastikan mereka realistis, baik selama desain dan setelah koreksi apa pun.
Sebagai SRE, kita harus memikirkan skalabilitas sistem nyata dalam batasan keterbatasan perangkat keras yang sebenarnya. Mungkin ada
algoritma yang indah yang menukar kompleksitas waktu raksasa dengan sejumlah RAM ... Tapi tetap saja, 1PiB RAM per 1 CPU bukanlah sesuatu yang bisa kita bangun hari ini. Jadi jika kita memiliki 1 PiB RAM, kita juga memiliki sekitar 10k CPU. Atau 20rb Atau bahkan 30rb. Itu berarti bahwa kita harus fokus pada optimal (lokal) nyata, yang dapat dicapai saat ini dalam kenyataan, dan bukan global yang dapat dicapai dalam kondisi ideal.
Anda seharusnya tidak mengingat angka yang tepat, tetapi Anda harus bisa menerapkan aturan praktis untuk mendapatkan pesanan besar. Seperti, IOPS: HDD sekitar 100an, SSD sekitar 100an ribuan. Tetapi 100 ribu ini datang dengan perbedaan harga antara HDD ke SSD seperti 1: 3 atau 1: 4. Ini juga mengabaikan segala sesuatu di sekitar: ruang rak, bilah untuk drive, port jaringan dan hal-hal lain, yang tidak lagi murah begitu Anda bekerja di peta dan skala.
Sekarang duduklah di kursi Anda, bersantailah, dan cobalah merancang sistem pertumbuhan dan pengiriman telur ayam segar dengan berlangganan.