Sumber terbuka adalah solusinya

Membangun perangkat lunak itu sulit. Membangun perangkat lunak cloud bahkan lebih sulit karena segala sesuatunya bergerak lebih cepat — dan membutuhkan keandalan dan ketersediaan yang sangat penting. Untuk membangun perangkat lunak secara efektif di cloud, tim teknik memerlukan observabilitas, CI/CD, pelaporan, dan banyak alat. Tetapi semua alat yang tersedia untuk tim teknik tidak pernah cocok satu sama lain dengan cara yang memberikan visibilitas dan konsistensi. Ketika terjadi kesalahan, pengembang berebut untuk memecahkan masalah sistem dengan data dan sistem yang berbeda.

Tim TechOps bertanggung jawab untuk menjaga semuanya tetap berjalan. Tetapi kumpulan alat yang tidak terintegrasi dengan baik menciptakan lingkungan di mana tim memiliki beberapa antarmuka dan kumpulan data untuk bertengkar saat mengoperasikan layanan penting. Tim sering mencoba memecahkan masalah ini dengan membuat integrasi satu kali dari alat yang tidak biasa dengan alat dan proses yang dikembangkan secara internal. Integrasi ini umumnya sangat dangkal, dan menciptakan beban pemeliharaan yang signifikan dan kesenjangan keandalan.

Integrasi khusus menyediakan lebih banyak tempat untuk menyimpan data dan kumpulan yang lebih luas untuk mencari, menghasilkan tampilan sumber data yang terdesentralisasi dan tidak ada cara mudah untuk kolaborasi pengembang. Yang dibutuhkan adalah pusat kendali berbasis open source untuk kolaborasi dan integrasi yang tepat dengan sistem saat ini — tidak perlu lagi menyalin dan menempel. Tetapi penting untuk membuat pusat pusat komando terpusat berfungsi untuk semua orang di organisasi‚Ķ bukan hanya pengembang garis depan dan SRE.

Tantangan di setiap level

Tantangan untuk pengoperasian, pemantauan, dan respons insiden ada di semua tingkat organisasi kita. Tim TechOps berfokus pada hosting, penerapan, dan keandalan layanan. Tim-tim ini memiliki perhatian khusus untuk ditangani sebelum, selama, dan setelah insiden potensial. Bagaimana pengembang bisa mendapatkan peringatan dini tentang pemadaman layanan? Bagaimana kita memilah volume besar data pemantauan untuk memecahkan masalah kegagalan? Bagaimana kita melacak status dan kemajuan selama insiden? Bagaimana kami mendokumentasikan pekerjaan yang telah dilakukan untuk memulihkan layanan? Bagaimana kami mengumpulkan semua informasi insiden yang relevan untuk dokumen retrospektif dan RCA?

Katakanlah ada masalah gangguan layanan. Di tingkat pengembang, tim memerlukan pemantauan dan data log yang mendetail. Memiliki pusat kendali terpusat memberikan akses yang lebih mudah ke data ini, meningkatkan efisiensi, dan menawarkan perspektif tentang cara memecahkan masalah di masa depan.

Pemimpin teknik memiliki tujuan yang kira-kira sama dengan pengembang di garis depan masalah ini, tetapi mereka lebih fokus pada tren tingkat tinggi yang berorientasi bisnis. Perspektif yang lebih luas ini berarti bahwa mereka terutama menginginkan tampilan data pemadaman yang tidak terlalu terperinci. Pengguna ini akan menghabiskan lebih banyak waktu mereka untuk fokus menganalisis tren pemadaman dari waktu ke waktu, memahami status saat ini dan langkah selanjutnya untuk insiden yang sedang berlangsung, dan memastikan komunikasi yang tepat dengan pemangku kepentingan internal dan eksternal.

Di tingkat Manajemen Senior, eksekutif membutuhkan jawaban tingkat tinggi untuk menjelaskan masalah kepada pelanggan mereka. Selama gangguan layanan besar, CEO sering berkomunikasi terus-menerus dengan pemangku kepentingan utama mereka untuk memberikan status tentang mengapa layanan turun. Daripada data pemadaman granular, diskusi ini mengandalkan wawasan bisnis tingkat tinggi tetapi terinformasi dan dapat ditindaklanjuti.

Mengatasi pemutusan dengan open source

Data yang jelas dan alur kerja kolaboratif sangat penting di setiap tingkat organisasi. Tetapi kekuatan sebenarnya terletak pada integrasi — bukan solusi yang berdiri sendiri. Dengan memanfaatkan fleksibilitas perangkat lunak sumber terbuka, tim dapat menciptakan sistem kolaborasi yang mengurangi waktu henti, menghindari kebingungan, mengaktifkan kecepatan, dan meningkatkan efisiensi.

Jika dibandingkan dengan sistem satu kali yang dikembangkan secara internal, solusi open source biasanya berskala lebih baik, memberikan kualitas dan keandalan yang lebih tinggi, dan menurunkan beban pemeliharaan keseluruhan untuk tim TechOps. Membuat proses Operasi yang disederhanakan dengan visibilitas dan integrasi yang tepat akan meningkatkan produktivitas developer. Ini juga meningkatkan kepuasan di tempat kerja dan membantu mengurangi kelelahan pengembang.

Salah satu masalah utama dengan perkakas internal khusus untuk TechOps adalah pemeliharaan. Perkakas ini dapat bekerja dengan baik saat pertama kali dibuat. Namun seiring waktu, perubahan persyaratan, dan pekerjaan pemeliharaan untuk perkakas internal sering kali berada di urutan terbawah daftar prioritas. Sementara itu, alat baru dimasukkan ke dalam tumpukan teknologi, dan dependensi umum tidak selalu diperbarui dan dikelola dengan tepat. Hasil? Perkakas yang kita semua andalkan rusak dengan cara yang buruk segera setelah kita mengalami insiden atau pemadaman. Hal ini membuat tim berebut untuk memulihkan layanan penting tanpa visibilitas dan kontrol yang tepat ke dalam sistem mereka.

Menerapkan solusi open source juga meningkatkan kemampuan tim untuk memelihara perangkat lunak yang diperlukan untuk memecahkan masalah di masa depan. Ketika organisasi mengadopsi open source, mereka mendapatkan akses ke sumber yang mendasarinya, didukung oleh komunitas kontributor independen, dengan ekstensibilitas berlapis yang fleksibel. Hal ini memungkinkan tim untuk mempercepat pemeliharaan dan penyebaran perangkat lunak sehingga mereka dapat fokus pada pemecahan masalah dengan cepat dan meningkatkan sistem untuk operasi yang lebih baik di masa depan.

Fleksibilitas adalah salah satu ciri utama yang dicari organisasi dalam pengembang. Tetapi untuk mencapai fleksibilitas penuh, perangkat lunak organisasi harus sesuai dengan harapan manusia ini. Tanpa open source yang memungkinkan fleksibilitas ini, TechOps berantakan. Di sisi lain, mengintegrasikan alat ke dalam tampilan terpusat membuat kolaborasi lintas organisasi lebih mudah dan mengatasi beragam tantangan di setiap tingkat organisasi modern.

Kredit Foto: Rawpixel.com/Shutterstock

Chris Overton adalah Vice President of Engineering di Mattermost, Inc. Sebelumnya, Chris memimpin engineering di Elastic, di mana dia juga bertanggung jawab atas divisi produk Cloud. Chris ahli dalam membangun dan mengoperasikan layanan SaaS publik dan hybrid, sistem terdistribusi, analitik/pemrosesan kumpulan data besar, dan pencarian.

Perangkat Lunak