Hey Habr! Aku menehi perhatian marang terjemahan artikel kasebut dening Adib Daw.
Yen judhul kasebut ora nggawe gemeter, sampeyan kudu pindhah menyang paragraf sabanjure utawa bukak kaca khusus kanggo - kita arep ngomong.
Sinten kita
Kita tim sing dumadi saka papat penguin sing seneng ngoding lan nggarap perangkat keras. Ing wektu luang, kita tanggung jawab kanggo masang, njaga, lan ngoperasikake armada luwih saka 7000 server fisik. Linux, kasebar ing 3 pusat data sing beda ing saindenging Amerika Serikat.
Kita uga duwe kesempatan kanggo nindakake iki 10 km adoh saka situs, saka comfort saka kantor dhewe, kang dumunung ing drive cendhak saka pantai ing Segara Mediterania.
Masalah skala
Nalika nggawe pangertèn kanggo wiwitan diwiwiti kanthi hosting infrastruktur ing méga amarga investasi awal sing relatif murah, kita ing Outbrain mutusake nggunakake server kita dhewe. Kita nindakake iki amarga biaya infrastruktur awan ngluwihi biaya operasi peralatan kita dhewe sing ana ing pusat data sawise pembangunan menyang tingkat tartamtu. Kajaba iku, server sampeyan nyedhiyakake tingkat kontrol lan kemampuan ngatasi masalah sing paling dhuwur.
Nalika kita berkembang, masalah tansah cedhak. Kajaba iku, biasane teka ing kelompok. Manajemen siklus urip server mbutuhake perbaikan diri sing terus-terusan supaya bisa mlaku kanthi bener ing konteks paningkatan cepet ing jumlah server. Cara piranti lunak kanggo ngatur grup server ing pusat data kanthi cepet dadi angel. Ndeteksi, ngatasi masalah, lan nyuda kegagalan nalika ketemu standar QoS dadi masalah juggling susunan hardware sing mawarni-warni, beban kerja sing beda-beda, wektu nganyarke, lan prekara-prekara liyane sing ora ana sing pengin kuwatir.
Master Domain Panjenengan
Kanggo ngatasi akeh masalah kasebut, kita ngilangi siklus urip server ing Outbrain dadi komponen utama lan diarani domain. Contone, siji domain nyakup syarat peralatan, liyane nyakup logistik sing ana gandhengane karo siklus urip inventaris, lan katelu nyakup komunikasi karo personel lapangan. Ana liyane babagan observability hardware, nanging kita ora bakal njlèntrèhaké kabeh TCTerms. Tujuan kita yaiku sinau lan nemtokake domain supaya bisa diabstraksi nggunakake kode. Sawise abstraksi sing digunakake dikembangake, ditransfer menyang proses manual sing disebarake, diuji, lan ditapis. Pungkasan, domain kasebut dikonfigurasi kanggo nggabungake karo domain liyane liwat API, mbentuk sistem siklus urip hardware sakabehe, dinamis, lan terus berkembang sing bisa disebarake, bisa diuji, lan bisa diamati. Kaya kabeh sistem produksi liyane.
Ngadopsi pendekatan iki ngidini kita ngrampungake akeh masalah kanthi bener - kanthi nggawe alat lan otomatisasi.
Perlu Domain
Sanajan email lan spreadsheet minangka cara sing sregep kanggo nyukupi panjaluk ing wiwitan, iki dudu solusi sing sukses, utamane nalika jumlah server lan volume panjaluk sing mlebu tekan level tartamtu. Kanggo luwih ngatur lan menehi prioritas panjaluk sing mlebu sajrone ekspansi kanthi cepet, kita kudu nggunakake sistem tiket sing bisa menehi:
- Kemampuan kanggo ngatur tampilan mung lapangan sing cocog (prasaja)
- Open API (bisa ditambah)
- Dikenal karo tim kita (dimangerteni)
- Integrasi karo alur kerja sing wis ana (manunggal)
Amarga nggunakake Jira kanggo ngatur sprint lan tugas internal, kita mutusake nggawe proyek liyane sing bakal mbantu klien ngirim tiket lan nglacak asile. Nggunakake Jira kanggo panjalukan sing mlebu lan kanggo ngatur tugas internal ngidini kita nggawe papan Kanban siji sing ngidini kita ndeleng kabeh proses kanthi wutuh. "Klien" internal kita mung ndeleng panjalukan kanggo peralatan, tanpa nyelidiki rincian tugas tambahan sing kurang penting (kayata nambah alat, ndandani kewan omo).
Papan Kanban ing Jira
Minangka bonus, kasunyatan manawa antrian lan prioritas saiki bisa dideleng kanggo kabeh wong bisa ngerteni "ing endi antrian" panjaluk tartamtu lan apa sing sadurunge. Iki ngidini para pamilik menehi prioritas maneh panjaluke dhewe tanpa kudu ngubungi kita. Seret lan sing. Iki uga ngidini kita ngawasi lan ngevaluasi SLA miturut jinis panjaluk adhedhasar metrik sing digawe ing Jira.
Domain Siklus Urip Peralatan
Coba mbayangno kerumitan ngatur hardware sing digunakake ing saben rak server. Apa malah Samsaya Awon iku akeh bêsik hardware (RAM, ROM) bisa dipindhah saka gudang kanggo kamar server lan bali. Padha uga gagal utawa ditulis mati lan diganti lan bali menyang supplier kanggo panggantos / ndandani. Kabeh iki kudu dilaporake menyang karyawan layanan colocation sing melu pangopènan fisik peralatan kasebut. Kanggo ngatasi masalah kasebut, kita nggawe alat internal sing diarani Floppy. Tugase yaiku:
- Manajemen komunikasi karo personel lapangan, agregasi kabeh informasi;
- Nganyari data "gudang" sawise saben proyek pangopènan peralatan rampung lan diverifikasi.
Gudang kasebut, digambarake nggunakake Grafana, sing digunakake kanggo ngrancang kabeh metrik. Mangkono, kita nggunakake alat sing padha kanggo visualisasi gudang lan kanggo kabutuhan produksi liyane.
Panel kontrol peralatan gudang ing Grafana
Kanggo piranti server sing ana ing garansi, kita nggunakake alat liyane sing diarani Dispatcher. Dheweke:
- Nglumpukake log sistem;
- Ngasilake laporan ing format sing dibutuhake dening vendor;
- Nggawe panjalukan saka vendor liwat API;
- Nampa lan nyimpen pengenal aplikasi kanggo nelusuri luwih maju.
Sawise pratelan kita ditampa (biasane ing jam kerja), spare part kasebut dikirim menyang pusat data sing cocog lan ditampa dening staf.
Output konsol Jenkins
Domain Komunikasi
Supaya bisa terus berkembang kanthi cepet ing bisnis kita, sing mbutuhake kapasitas sing saya tambah akeh, kita kudu ngganti cara kerjane karo spesialis teknis ing pusat data lokal. Yen pisanan scaling munggah tegese tuku server anyar, banjur sawise project consolidation (adhedhasar transisi kanggo Kubernetes) dadi soko temen beda. Evolusi kita saka "nambahake rak" dadi "server repurposing."
Nggunakake pendekatan anyar uga mbutuhake alat anyar sing ndadekake bisa sesambungan luwih nyaman karo personel pusat data. Piranti kasebut dibutuhake kanggo:
- Kesederhanaan;
- Otonomi;
- Efisiensi;
- Linuwih.
Kita kudu ngilangi awake dhewe saka rantai lan nggawe struktur kerja supaya teknisi bisa langsung nggarap peralatan server. Tanpa campur tangan kita lan tanpa rutin ngunggahake kabeh masalah kasebut babagan beban kerja, jam kerja, kasedhiyan peralatan, lsp.
Kanggo entuk iki, kita nginstal iPads ing saben pusat data. Sawise nyambungake menyang server, ing ngisor iki bakal kelakon:
- Piranti kasebut nandheske manawa server iki pancen mbutuhake sawetara karya;
- Aplikasi sing mlaku ing server ditutup (yen perlu);
- Sakumpulan instruksi kerja dikirim ing saluran Slack sing nerangake langkah-langkah sing dibutuhake;
- Sawise rampung karya, piranti mriksa bener saka negara final saka server;
- Wiwiti maneh aplikasi yen perlu.
Kajaba iku, kita uga nyiapake bot Slack kanggo mbantu teknisi. Thanks kanggo macem-macem kabisan (kita terus-terusan ngembangake fungsi kasebut), bot nggawe karyane luwih gampang, lan nggawe urip luwih gampang. Kanthi cara iki, kita ngoptimalake sebagian besar proses repurposing lan njaga server, ngilangi awake dhewe saka alur kerja.
iPad ing salah sawijining pusat data kita
Domain Hardware
Kanthi andal skala infrastruktur pusat data kita mbutuhake visibilitas sing apik ing saben komponen, contone:
- Deteksi kegagalan hardware
- Status server (aktif, host, zombie, lsp.)
- Konsumsi Daya
- Versi firmware
- Analytics kanggo kabeh bisnis iki
Solusi kita ngidini kita nggawe keputusan babagan kepiye, ing endi lan kapan tuku peralatan, kadhangkala sadurunge dibutuhake. Uga, kanthi nemtokake tingkat beban ing macem-macem peralatan, kita bisa entuk alokasi sumber daya sing luwih apik. Utamane, konsumsi energi. Saiki kita bisa nggawe keputusan sing ngerti babagan penempatan server sadurunge dipasang ing rak lan disambungake menyang sumber daya, sajrone siklus urip lan nganti pensiun.
Dashboard Energi ing Grafana
Lan banjur COVID-19 muncul ...
Tim kita nggawe teknologi sing nguatake perusahaan media lan penerbit online kanggo mbantu pengunjung nemokake konten, produk, lan layanan sing relevan sing bisa dadi kapentingan kanggo dheweke. Infrastruktur kita dirancang kanggo ngladeni lalu lintas sing diasilake nalika sawetara warta sing nyenengake dirilis.
Liputan media sing kuat ing sekitar COVID-19, ditambah karo paningkatan lalu lintas, tegese kita kudu sinau babagan cara ngatasi tekanan kasebut. Kajaba iku, kabeh iki kudu ditindakake sajrone krisis global, nalika ranté pasokan kaganggu lan umume staf ana ing omah.
Nanging, kaya sing wis dingerteni, model kita wis nganggep manawa:
- Peralatan ing pusat data kita, umume, ora bisa diakses sacara fisik kanggo kita;
- Kita nindakake meh kabeh karya fisik mbatalake;
- Pakaryan ditindakake kanthi ora sinkron, otonom lan kanthi skala gedhe;
- Kita nyukupi kabutuhan peralatan kanthi nggunakake metode "bangun saka bagean" tinimbang tuku peralatan anyar;
- Kita duwe gudang sing ngidini kita nggawe sing anyar, lan ora mung nindakake ndandani rutin.
Mangkono, watesan global sing nyegah akeh perusahaan entuk akses fisik menyang pusat data ora ana pengaruhe kanggo kita Lan kanggo suku cadang lan server, ya, kita nyoba kanggo njamin operasi sing stabil. Nanging iki ditindakake kanthi tujuan kanggo nyegah kedadeyan sing bisa kedadeyan nalika tiba-tiba dadi sawetara piranti keras ora kasedhiya. Kita mesthekake yen cadangan kita diisi tanpa tujuan kanggo nyukupi kabutuhan saiki.
Ing ringkesan, aku pengin ujar manawa pendekatan kita kanggo kerja ing industri pusat data mbuktekake manawa bisa ngetrapake prinsip desain kode sing apik kanggo proses manajemen pusat data fisik. Lan mbok menawa sampeyan bakal nemokake iku menarik.
Asli:
Source: www.habr.com
