Apa Arsitektur Dapat Mengajari Kita Tentang Sistem Penyembuhan Diri

Tim DevOps dan insinyur keandalan situs (SRE) menangani kode setiap hari. Melakukan hal itu mengajarkan mereka untuk meneliti dunia mereka, melakukan pengamatan yang cerdik, dan menarik koneksi yang tidak terduga. Lagi pula, meskipun sangat logis dan matematis, pengembangan perangkat lunak, setidaknya sebagian, adalah bentuk seni. 

Tidak yakin dengan pernyataan itu? Pertimbangkan kesejajaran antara prestasi arsitektur paling luar biasa dalam sejarah dan rekayasa perangkat lunak modern. Ini adalah perbandingan yang tepat: Sama seperti rekayasa perangkat lunak, arsitektur menggunakan perhitungan matematis yang rumit untuk menciptakan sesuatu yang indah. Dan di kedua disiplin ilmu, sedikit kesalahan perhitungan dapat menyebabkan konsekuensi yang signifikan. Menariknya, banyak kesalahan arsitektur terkenal yang serupa dengan masalah yang kami temukan dalam kode.

Ingat, inspirasi ada di mana-mana – selama Anda tahu ke mana mencarinya. Berikut adalah beberapa pelajaran yang dapat dipelajari oleh insinyur perangkat lunak dari pencerahan arsitektur selama berabad-abad, terutama mengenai masa depan sistem penyembuhan diri.

Pelajaran 1: Kasus Edge akan selalu mengeksploitasi kerentanan sistem

Citicorp Tower – sekarang disebut 601 Lexington – selesai dibangun di New York City pada tahun 1977, saat itu merupakan gedung tertinggi ketujuh di dunia. Desain gedung pencakar langit yang canggih mencakup tiga panggung setinggi 100 kaki lebih. Itu adalah keajaiban saat penyelesaian. Namun, seorang mahasiswa sarjana segera menemukan sesuatu yang menggelegar: Angin kencang dapat membahayakan keutuhan bangunan. Secara khusus, jika angin quartering yang kuat menghantam sudut Menara Citicorp, struktur tersebut dapat runtuh - secara harfiah kasus tepi.

Menara ini memiliki peluang satu banding 16 untuk runtuh setiap tahun. Peluang ini mungkin memikat seseorang yang duduk di meja judi, tetapi prospeknya suram bagi para arsitek dan insinyur struktur di belakang Citicorp Tower. Syukurlah, teknisi dapat memperkuat sambungan baut gedung. Bencana dihindari.

Insinyur struktur tahu Menara Citicorp pada akhirnya akan menghadapi angin yang cukup kuat untuk mengkompromikan bantalannya. Demikian pula, insinyur perangkat lunak berpengalaman tahu pemantauan kinerja aplikasi (APM) yang kuat dan manajemen acara tidak cukup untuk melindungi sistem dari kasus tepi yang tak terhindarkan. Itu karena sistem statis tanpa pembelajaran mesin (ML) kemampuan tidak dapat menangani situasi baru yang tidak terduga dan tidak terencana, seperti angin kuarter. Saat hanya mengandalkan alat pemantauan, administrator manusia harus menguraikan kesalahan dan meningkatkan proses manajemen insiden.

Untuk mengurangi waktu rata-rata untuk memulihkan (MTTR)/rata-rata waktu untuk mendeteksi (MTTD), tim DevOps harus menerima kemungkinan kasus edge yang tinggi dan berupaya menerapkan solusi pembelajaran mandiri terlebih dahulu. Pelajaran ini sangat bermanfaat, karena pandangan jauh ke depan sangat penting dalam bidang teknik.

Pelajaran 2: "Membangun pesawat saat terbang" menciptakan siklus tanpa akhir

Peristiwa tragis telah menyebabkan beberapa di antaranya pelajaran terpenting dalam sejarah penerbangan. Ketika sebuah pesawat mengalami dekompresi yang sangat besar di tengah penerbangan dan jatuh pada tahun 1954, para insinyur memastikan bahwa jendela penumpang persegi adalah titik stres yang tidak perlu. Untuk selanjutnya, pesawat dilengkapi dengan jendela bundar. Kebakaran di atas kapal menyebabkan pengaturan tempat duduk baru yang memprioritaskan kemudahan evakuasi. Perubahan ini telah menyelamatkan banyak nyawa.

Di banyak industri – termasuk penerbangan – tidak ada cara untuk menguji stres produk secara mendalam. Seperti disebutkan sebelumnya, kasus tepi tidak dapat dihindari. Pengambilan terbesar di sini adalah bahwa insinyur perangkat lunak harus memperhatikan kerentanan sistem mereka ketika mereka menampilkan diri. Dari sana, mereka harus mengatasinya dengan bijaksana. Melakukan hal itu memerlukan dua hal: (1) mengidentifikasi dan melacak indikator kinerja utama (KPI) yang tepat dan (2) menginvestasikan waktu dan sumber daya untuk meningkatkan sistem berdasarkan metrik yang relevan.

Rata-rata tim teknik berinvestasi dalam 16 hingga 40 alat pemantauan, namun mereka sering meleset dari metrik yang menunjukkan keberhasilan. Kurang dari 15% tim melacak MTTD, sehingga mereka melewatkan 66% siklus hidup insiden. Dan seperempat dari tim melaporkan kehilangan perjanjian tingkat layanan (SLA) mereka meskipun investasi yang signifikan dalam pelacakan ketersediaan. Ini memberi tahu kita bahwa pengumpulan data membutuhkan analisis yang menyeluruh dan sistematis untuk memotongnya– solusi titik tidak lagi cukup.

Insinyur perangkat lunak, tim DevOps, dan SRE harus memprioritaskan proses dan alat yang mengekstraksi nilai dari sejumlah besar informasi tentang ketersediaan. Alih-alih hanya mengamati kesalahan kritis, mereka harus mengambil satu halaman dari buku insinyur penerbangan dan membuat keputusan penting dengan cepat. Rahasia untuk melakukannya terletak pada AI.

Pelajaran 3: AI adalah blok bangunan mendasar untuk sistem penyembuhan diri

Sistem penyembuhan diri yang sepenuhnya otonom, berfungsi sempurna, sangat ideal untuk setiap insinyur perangkat lunak. Sistem yang menambal sendiri bagus untuk kepuasan pelanggan, karena menghilangkan waktu henti yang merugikan konsumen. Selain itu, mereka sangat bermanfaat untuk fungsi manajemen layanan TI (ITSM), karena secara signifikan mengurangi kebutuhan akan manajemen tiket yang membosankan. Membangun sistem seperti itu membutuhkan beberapa komponen, banyak di antaranya saat ini tidak terjangkau. Tetapi kita lebih dekat dengan realitas penyembuhan diri daripada yang disadari beberapa orang.

Kurangnya adopsi AI secara luas tetap menjadi rintangan terbesar yang dihadapi sistem penyembuhan diri saat ini. Meskipun banyak bisnis telah mengadopsi alat berbasis AI atau ML yang belum sempurna, integritas alat ini dipertanyakan. Artinya, banyak insinyur berurusan dengan kecerdasan buatan untuk operasi TI (AIOps) teknologi yang mengikuti logika otomasi berbasis aturan alih-alih algoritme AI otonom. Perbedaannya mungkin tampak kecil, tetapi dalam praktiknya, itu adalah perbedaan antara jam produktivitas yang hilang dan jutaan kerugian yang mungkin terjadi.

Masalahnya, alat AIOps berbasis aturan menganalisis interaksi antara solusi titik yang berbeda dan kemungkinan dapat mengidentifikasi kesalahan data yang umum. Tetapi sistem berbasis otomasi tidak dapat memproses evolusi kesalahan yang sama sekali baru dari waktu ke waktu, juga tidak dapat memprediksi malfungsi baru dalam data. Itu karena administrator manusia yang mengkodekan fungsi-fungsi ini meminta sistem untuk mengikuti an jika ini, maka itu pola logika. Alat AIOps yang benar-benar efisien mengurangi kesalahan yang muncul di keempat titik telemetri klasik – mulai dari deteksi hingga resolusi – dengan mengklasifikasikan pola baru dan bermasalah bahkan sebelum teknisi manusia menyadari keberadaannya. 

Sementara kita menunggu gelombang ketiga AI yang akan segera terjadi, versi AIOps ini adalah yang terdekat dengan sistem penyembuhan diri. Akan menarik untuk melacak bagaimana aplikasi AIOps saat ini mengalir ke masa depan AI, yang akan mencakup otomatisasi yang terwujud sepenuhnya dan kemungkinan pemikiran independen. Mungkin kemudian insinyur struktural juga akan menuai hasil dari sistem penyembuhan diri berbasis AI.

• Konten Bertenaga SEO & Distribusi PR. Dapatkan Amplifikasi Hari Ini.
• Platoblockchain. Intelijen Metaverse Web3. Pengetahuan Diperkuat. Akses Di Sini.
• Sumber: https://www.dataversity.net/what-architecture-can-teach-us-about-self-healing-systems/