Perusahaan kami sedang dalam proses memasukkan tim SRE. Saya memahami keseluruhan cerita ini dari sisi pengembangan. Dalam prosesnya, saya mendapatkan pemikiran dan wawasan yang ingin saya bagikan dengan pengembang lain. Dalam artikel refleksi ini saya berbicara tentang apa yang sedang terjadi, bagaimana hal itu terjadi, dan bagaimana setiap orang dapat terus menjalaninya.
Kelanjutan dari rangkaian artikel yang ditulis berdasarkan pidato di acara internal kami :
2. Infrastruktur sebagai kode. (Kamu di sini)
3. Pembuatan kontrak TypeScript menggunakan model C#. (Sedang berlangsung...)
4. Pengenalan algoritma konsensus Raft. (Sedang berlangsung...)
...
Kami memutuskan untuk membentuk tim SRE, mengimplementasikan ide-ide tersebut . Mereka merekrut programmer dari kalangan pengembang mereka sendiri dan mengirim mereka untuk dilatih selama beberapa bulan.
Tim memiliki tugas pelatihan berikut:
- Jelaskan infrastruktur kami yang sebagian besar ada di Microsoft Azure dalam bentuk kode (Terraform dan segala sesuatu di sekitarnya).
- Ajari pengembang cara bekerja dengan infrastruktur.
- Mempersiapkan pengembang untuk bertugas.
Kami memperkenalkan konsep Infrastruktur sebagai kode
Dalam model dunia yang lazim (pemerintahan klasik), pengetahuan tentang infrastruktur terletak di dua tempat:
- Atau berupa pengetahuan di kepala para ahli.
- Atau informasi ini ada pada beberapa mesin ketik, beberapa di antaranya diketahui oleh para ahli. Namun bukan fakta bahwa orang luar (jika seluruh tim kami tiba-tiba mati) akan dapat mengetahui apa yang berhasil dan bagaimana cara kerjanya. Ada banyak informasi di mesin: aksesori, cronjobs, terintimidasi (lihat. ) disk dan daftar tanpa akhir tentang apa yang bisa terjadi. Sulit untuk memahami apa yang sebenarnya terjadi.
Dalam kedua kasus tersebut, kita mendapati diri kita terjebak dalam ketergantungan:
- atau dari seseorang yang fana, rentan terhadap penyakit, jatuh cinta, perubahan suasana hati, dan PHK biasa saja;
- atau dari mesin yang berfungsi secara fisik, yang juga terjatuh, dicuri, dan menimbulkan kejutan serta ketidaknyamanan.
Idealnya segala sesuatu harus diterjemahkan ke dalam kode yang dapat dibaca manusia, dipelihara, dan ditulis dengan baik.
Dengan demikian, infrastruktur sebagai kode (Incfastructure as Code - IaC) adalah gambaran dari seluruh infrastruktur yang ada dalam bentuk kode, serta alat terkait untuk bekerja dengannya dan mengimplementasikan infrastruktur nyata darinya.
Mengapa menerjemahkan semuanya ke dalam kode?Manusia bukanlah mesin. Mereka tidak dapat mengingat semuanya. Reaksi manusia dan mesin berbeda. Apa pun yang dilakukan secara otomatis berpotensi lebih cepat daripada apa pun yang dilakukan oleh manusia. Yang terpenting adalah satu sumber kebenaran.
Dari mana asal insinyur SRE baru?Jadi, kami memutuskan untuk merekrut insinyur SRE baru, tapi dari mana mendapatkannya? Buku dengan jawaban yang benar () memberi tahu kita: dari pengembang. Bagaimanapun, mereka bekerja dengan kode, dan Anda mencapai keadaan ideal.
Kami banyak mencari mereka dalam waktu lama di pasar personel di luar perusahaan kami. Namun harus kami akui bahwa kami tidak menemukan orang yang sesuai dengan permintaan kami. Saya harus mencari di antara orang-orang saya sendiri.
Masalah Infrastruktur sebagai kode
Sekarang mari kita lihat contoh bagaimana infrastruktur dapat di-hardcode menjadi kode. Kode ditulis dengan baik, berkualitas tinggi, dengan komentar dan lekukan.
Contoh kode dari Terraforma.
Contoh kode dari Ansible.
Tuan-tuan, andai saja sesederhana itu! Kami berada di dunia nyata, dan dunia selalu siap mengejutkan Anda, menghadirkan kejutan dan masalah. Di sini juga tidak bisa hidup tanpa mereka.
1. Masalah pertama adalah bahwa dalam banyak kasus IaC adalah sejenis dsl.
Dan DSL, pada gilirannya, adalah deskripsi strukturnya. Lebih tepatnya, yang harus Anda miliki: Json, Yaml, modifikasi dari beberapa perusahaan besar yang membuat dslnya sendiri (HCL digunakan di terraform).
Masalahnya adalah bahwa hal tersebut mungkin tidak memuat hal-hal umum seperti:
- variabel;
- kondisi;
- di suatu tempat tidak ada komentar, misalnya di Json, secara default tidak disediakan;
- fungsi;
- dan saya bahkan tidak membicarakan hal-hal tingkat tinggi seperti kelas, warisan, dan sebagainya.
2. Masalah kedua dengan kode tersebut adalah seringkali lingkungannya heterogen. Biasanya Anda duduk dan bekerja dengan C#, mis. dengan satu bahasa, satu tumpukan, satu ekosistem. Dan di sini Anda memiliki beragam teknologi.
Ini adalah situasi yang sangat nyata ketika bash dengan python meluncurkan beberapa proses di mana Json dimasukkan. Anda menganalisisnya, lalu generator lain menghasilkan 30 file lainnya. Untuk semua ini, variabel masukan diterima dari Azure Key Vault, yang disatukan oleh plugin untuk drone.io yang ditulis dalam Go, dan variabel-variabel ini melewati yaml, yang dihasilkan sebagai hasil pembangkitan dari mesin templat jsonnet. Cukup sulit untuk memiliki kode yang dijelaskan dengan baik ketika Anda memiliki lingkungan yang beragam.
Perkembangan tradisional dalam kerangka satu tugas hadir dengan satu bahasa. Di sini kami bekerja dengan banyak bahasa.
3. Masalah ketiga adalah penyetelan. Kami terbiasa dengan editor keren (Ms Visual Studio, Jetbrains Rider) yang melakukan segalanya untuk kami. Dan meskipun kita bodoh, mereka akan mengatakan bahwa kita salah. Tampaknya normal dan alami.
Tetapi di suatu tempat di dekatnya ada VSCode, yang di dalamnya terdapat beberapa plugin yang entah bagaimana diinstal, didukung atau tidak didukung. Versi baru keluar dan tidak didukung. Transisi dangkal dalam mengimplementasikan suatu fungsi (walaupun ada) menjadi masalah yang kompleks dan tidak sepele. Penggantian nama variabel yang sederhana adalah pemutaran ulang selusin file dalam proyek. Anda akan beruntung jika dia memberikan apa yang Anda butuhkan. Tentu saja, ada lampu latar di sana-sini, ada pelengkapan otomatis, di suatu tempat ada pemformatan (walaupun saya tidak berhasil di terraform di Windows).
Pada saat penulisan ini belum dirilis untuk mendukung versi 0.12, padahal sudah dirilis selama 3 bulan.
Saatnya melupakan...
- Debug.
- Alat pemfaktoran ulang.
- Penyelesaian otomatis.
- Mendeteksi kesalahan selama kompilasi.
Ini lucu, tapi ini juga menambah waktu pengembangan dan meningkatkan jumlah kesalahan yang pasti terjadi.
Yang terburuk adalah kita dipaksa untuk berpikir bukan tentang bagaimana mendesain, mengatur file ke dalam folder, menguraikan, membuat kode dapat dipelihara, dibaca, dan sebagainya, tetapi tentang bagaimana saya dapat menulis perintah ini dengan benar, karena entah bagaimana saya salah menulisnya. .
Sebagai seorang pemula, Anda mencoba mempelajari terraform, dan IDE tidak membantu Anda sama sekali. Jika ada dokumentasi, masuk dan lihat. Tetapi jika Anda memasuki bahasa pemrograman baru, IDE akan memberitahu Anda bahwa ada tipe seperti itu, tetapi tidak ada yang seperti itu. Setidaknya pada level int atau string. Hal ini seringkali berguna.
Bagaimana dengan tesnya?
Anda bertanya: “Bagaimana dengan tesnya, Tuan-tuan programmer?” Orang-orang yang serius menguji semuanya dalam produksi, dan itu sulit. Berikut adalah contoh pengujian unit untuk modul terraform dari website .
Mereka memiliki dokumentasi yang bagus. Saya selalu menyukai Microsoft karena pendekatannya terhadap dokumentasi dan pelatihan. Namun Anda tidak perlu menjadi Paman Bob untuk memahami bahwa ini bukanlah kode yang sempurna. Perhatikan validasi di sebelah kanan.
Masalah dengan pengujian unit adalah Anda dan saya dapat memeriksa kebenaran keluaran Json. Saya memasukkan 5 parameter dan diberi alas kaki Json dengan 2000 garis. Saya dapat menganalisis apa yang terjadi di sini, memvalidasi hasil tes...
Sulit untuk mengurai Json di Go. Dan Anda perlu menulis di Go, karena terraform di Go adalah praktik yang baik untuk menguji dalam bahasa yang Anda gunakan untuk menulis. Organisasi kodenya sendiri sangat lemah. Pada saat yang sama, ini adalah perpustakaan terbaik untuk pengujian.
Microsoft sendiri yang menulis modulnya, mengujinya dengan cara ini. Tentu saja itu Open Source. Segala sesuatu yang saya bicarakan dapat Anda datangi dan perbaiki. Saya bisa duduk dan memperbaiki semuanya dalam seminggu, plugin kode VS open source, terraform, membuat plugin untuk pengendara. Mungkin menulis beberapa penganalisis, menambahkan linter, menyumbangkan perpustakaan untuk pengujian. Saya bisa melakukan segalanya. Tapi bukan itu yang seharusnya aku lakukan.
Praktik terbaik Infrastruktur sebagai kode
Mari kita lanjutkan. Jika tidak ada pengujian di IaC, IDE dan penyetelannya buruk, setidaknya harus ada praktik terbaik. Saya baru saja membuka Google Analytics dan membandingkan dua kueri penelusuran: praktik terbaik Terraform dan praktik terbaik c#.
Apa yang kita lihat? Statistik yang kejam tidak menguntungkan kita. Jumlah bahannya sama. Dalam pengembangan C#, kami hanya kebanjiran materi, kami memiliki praktik super terbaik, ada buku yang ditulis oleh para ahli, dan juga buku yang ditulis berdasarkan buku oleh pakar lain yang mengkritik buku tersebut. Lautan dokumentasi resmi, artikel, kursus pelatihan, dan kini juga pengembangan open source.
Adapun permintaan IaC: di sini Anda mencoba mengumpulkan informasi sedikit demi sedikit dari laporan highload atau HashiConf, dari dokumentasi resmi dan berbagai masalah di Github. Bagaimana cara mendistribusikan modul-modul ini secara umum, apa yang harus dilakukan dengannya? Tampaknya ini adalah masalah nyata... Ada komunitas, Tuan-tuan, di mana untuk pertanyaan apa pun Anda akan diberikan 10 komentar di Github. Tapi itu tidak sepenuhnya benar.
Sayangnya, saat ini, para ahli baru mulai bermunculan. Jumlah mereka sejauh ini terlalu sedikit. Dan komunitas itu sendiri berada pada tingkat yang belum sempurna.
Kemana arah semua ini dan apa yang harus dilakukan
Anda dapat meninggalkan semuanya dan kembali ke C#, ke dunia pengendara. Tapi tidak. Mengapa Anda repot-repot melakukan hal ini jika Anda tidak dapat menemukan solusinya. Di bawah ini saya menyajikan kesimpulan subjektif saya. Anda bisa berdebat dengan saya di komentar, itu akan menarik.
Secara pribadi, saya bertaruh pada beberapa hal:
- Perkembangan di bidang ini terjadi dengan sangat cepat. Berikut adalah jadwal permintaan DevOps.
Topiknya mungkin hype, namun fakta bahwa bidang ini terus berkembang memberikan sedikit harapan.Jika sesuatu tumbuh begitu cepat, maka pasti akan muncul orang-orang pintar yang akan memberi tahu Anda apa yang harus dilakukan dan apa yang tidak boleh dilakukan. Meningkatnya popularitas mengarah pada fakta bahwa mungkin seseorang akhirnya punya waktu untuk menambahkan plugin ke jsonnet untuk vscode, yang memungkinkan Anda melanjutkan mengimplementasikan fungsi tersebut, daripada mencarinya melalui ctrl+shift+f. Seiring berkembangnya berbagai hal, semakin banyak material yang muncul. Peluncuran buku dari Google tentang SRE adalah contoh yang bagus untuk hal ini.
- Ada teknik dan praktik yang dikembangkan dalam pengembangan konvensional yang dapat kita terapkan dengan sukses di sini. Ya, ada perbedaan dalam pengujian dan lingkungan yang heterogen, peralatan yang tidak memadai, tetapi sejumlah besar praktik telah dikumpulkan yang dapat berguna dan membantu.
Contoh sepele: kolaborasi melalui pemrograman berpasangan. Ini sangat membantu untuk mengetahuinya. Ketika Anda memiliki tetangga di dekat Anda yang juga mencoba memahami sesuatu, bersama-sama Anda akan lebih memahaminya.
Memahami bagaimana refactoring dilakukan membantu melaksanakannya bahkan dalam situasi seperti itu. Artinya, Anda tidak bisa mengubah semuanya sekaligus, tetapi mengubah penamaan, lalu mengubah lokasi, lalu Anda dapat menyorot beberapa bagian, oh, tetapi komentar di sini tidak cukup.
Kesimpulan
Terlepas dari kenyataan bahwa alasan saya mungkin tampak pesimis, saya menatap masa depan dengan harapan dan dengan tulus berharap semuanya akan berhasil bagi kami (dan Anda).
Bagian kedua dari artikel ini sedang dipersiapkan selanjutnya. Di dalamnya, saya akan berbicara tentang bagaimana kami mencoba menggunakan praktik pembangunan tangkas untuk meningkatkan proses pembelajaran dan bekerja dengan infrastruktur.
Sumber: www.habr.com