Selama bertahun-tahun, Netcracker telah menjadi vendor produk untuk operator telekomunikasi, dan pada saat yang sama bertindak sebagai integrator dari seluruh jajaran perangkat lunak operator. Dalam karya ini, tugas tak terhindarkan muncul dari sinkronisasi dan koordinasi sejumlah besar versi produk dan solusi, dalam kombinasi yang berbeda, dari pengembang yang berbeda dan dengan fungsionalitas yang berbeda. Banyak operator sengaja menghindari ketergantungan pada satu pemasok dengan menciptakan kebun binatang produk dari vendor yang berbeda, sehingga dalam skenario yang agak rumit hingga beberapa lusinan sistem dan proses yang berbeda dapat terlibat.
Untuk memperjelas tentang hal ini, bayangkan bahwa sekali seminggu Anda perlu menerapkan proses menggunakan seperangkat alat dan teknologi yang berbeda: prosedur PL / SQL, skrip bash, skrip Perl, meluncurkan aplikasi individual dan mengakses proses daemon. Ini semua karena heterogenitas lanskap IT operator. Pada saat yang sama, untuk setiap prosedur akan ada parameter peluncurannya sendiri, kontrol keluar, serta serangkaian kesalahan yang mungkin mempengaruhi eksekusi skrip selanjutnya. Setiap peluncuran seperti itu berubah menjadi tugas serius yang membutuhkan beberapa jam atau hari kerja para insinyur IT berkualifikasi tinggi - pelatihan mereka dapat memakan waktu hingga tiga tahun sebelum mereka dapat dirilis ke operator telekomunikasi yang produktif dengan puluhan juta pengguna.
Jelas bahwa tugas-tugas ini perlu diotomatisasi. Oleh karena itu, kami memutuskan untuk mengambil yang terbaik dari BPMN Orchestra, perencana proses, sistem pemantauan dan memperkaya set ini dengan kemampuan untuk mengurai log dan kesalahan. Tentu saja, perwakilan terbaik dari jenisnya dipertimbangkan untuk setiap jenis sistem. Tetapi tidak ada esensi yang cocok ditemukan untuk spesifik industri. Karena itu - lakukan sendiri.
Secara singkat tentang apa yang kita lakukan: prosedur heterogen dikemas ke dalam "tugas" dengan seperangkat antarmuka dan properti yang khas; urutan tugas tertentu membentuk "proses" (misalnya, proses penagihan untuk biaya layanan komunikasi). Selanjutnya, sesuai dengan jadwal atau secara manual, setiap proses memulai urutan prosedurnya dengan parameter yang diperlukan, memantau pelaksanaan, mengevaluasi hasil tugas bersarang, dan membuat keputusan tentang pilihan skrip. Interkoneksi antara tugas-tugas dalam proses didasarkan pada logika BPMN standar, sementara di server manajemen kami meletakkan kemampuan untuk menghentikan proses secara manual, menghentikannya, keluar dari skenario saat ini dengan menyimpan data yang diproses. Manajemen proses diimplementasikan melalui antarmuka web dengan pemantauan real-time, dengan penilaian anomali, pemantauan SLA spesifik untuk setiap proses.
Sekarang "manajer proses" kami dapat bekerja dalam mode semi-otomatis, tetapi praktis tidak mengurangi beban pada insinyur TI - ketika dua atau lebih sistem kompleks berinteraksi, variabilitas anomali dalam proses meningkat berkali-kali dan upaya utama jatuh pada penanganan kesalahan. Oleh karena itu, pada tahap selanjutnya, kami harus membuat keputusan:
- Bagaimana kita ingin mengotomatiskan penanganan kesalahan?
- Bagaimana cara memperbaiki skenario berdasarkan analisis anomali?
- Secara umum, seberapa banyak seseorang harus campur tangan dalam pengoperasian sistem seperti itu, dalam volume apa dan di tempat apa?
Saya perhatikan sekali lagi bahwa semua ini perlu dilakukan secara real time pada produktivitas sistem kritis-misi yang melayani puluhan dan ratusan ribu transaksi per detik. Dan di sini kami harus menyelesaikan masalah pencarian dan pemecahan masalah (yang disebut pemecahan masalah) dalam kondisi:
- pembaruan berkala dalam proses
- mengembangkan basis operator
- perubahan dalam set layanan telekomunikasi
Ya, dan syarat penting lain yang harus kita patuhi adalah tidak membahayakan. Atau berbicara dalam bahasa dokumen resmi - untuk mengurangi waktu dan biaya tenaga kerja dalam pengoperasian sistem TI penyedia telekomunikasi.
Timbul pertanyaan - dalam proporsi apa seharusnya penanganan kesalahan otomatis dan partisipasi pakar dalam pemecahan masalah seperti itu dicampur. Selanjutnya, mari kita bicara tentang opsi.
AI
Karena kita hidup di era hype abadi, kami memutuskan untuk menjadikan pengembangan sebagai basis kecerdasan buatan - sehingga kecerdasan ini mengenali kesalahan dan anomali, memprediksi kegagalan, dan segera memperbaikinya. Perusahaan besar dan startup kecil sudah menciptakan itu dan bahkan menerapkan solusi serupa. Ruang lingkup utama aplikasi mereka: operasi untuk konstruksi, pemeliharaan dan dukungan infrastruktur TI. Ini disebut Operasi AIOps - Aritificial Intelligence (untuk IT), dan kata kunci paling populer adalah NoOps, mis., Operasi TI yang sepenuhnya otomatis.
Mempelajari sistem tidak akan mudah, karena kumpulan data historis terbatas, mahal untuk membuat salinan produk yang tepat, dan mengajar contoh-contoh (pembelajaran aktif) terlalu lama dan, dalam kasus kami, tidak akurat. Anda dapat mencoba metode agregasi bootstrap - untuk mensimulasikan sekumpulan skrip hingga kasus yang diketahui dan diduga dan membuat pohon keputusan berdasarkan itu, misalnya, Klasifikasi dan Regresi Pohon, tetapi ini juga metode yang cukup mahal. Tetapi jika kita melakukan semua ini, kita akan membuat program berpikir untuk kita dan menghemat banyak sumber daya yang berguna (yang, diterjemahkan dari manajerial ke manusia, berarti "memecat administrator sistem yang paling menyebalkan").
Cons:
- Karena kerumitan sistem dan interaksinya, praktis tidak mungkin untuk membuat dan melatih versi "kotak" tertentu dari solusi semacam itu untuk semua situasi yang mungkin. Untuk setiap proyek baru, ini akan menjadi "kursus pelatihan" terpisah, dengan pengakuan kesalahan spesifik, anomali dan cara yang tepat untuk menyelesaikannya.
- Kami tidak merancang solusi massal, tetapi solusi internal, untuk sejumlah implementasi terbatas (karena ada sangat sedikit operator skala ini di dunia). Ini dapat dengan mudah berubah sehingga akan lebih ekonomis untuk menawarkan pelanggan kami outsourcing "manusia" yang tepat untuk menyelesaikan masalah tersebut.
- Mungkin pelanggan kami lebih mungkin menanggung biaya insinyur baru yang berkualifikasi tinggi daripada mengambil risiko mentransfer dukungan produk ke kecerdasan buatan. Singkatnya, ini bisa menimbulkan beberapa kekhawatiran.
Bukan AI saya otak
Karena intervensi manusia tidak dapat ditiadakan, kami pergi dengan cara kuno. Ingat, begitu kita berpikir bahwa "mesin harus bekerja, dan seseorang harus berpikir"? Kami merumuskan ulang ini: "program harus menyelesaikan masalah yang diketahui, dan insinyur harus menyelesaikan yang tidak diketahui."
Kami menciptakan sistem algoritmik yang tertata dalam konsep pembelajaran yang diperkuat, tetapi dengan logika yang jelas. Pelatihan sistem berlangsung dalam volume yang sempit dan terkontrol, aturan disimpan secara transparan, dapat diedit, diperluas, ditentukan, dinonaktifkan, dll. Perkembangan semacam itu tidak jauh lebih rumit daripada "semi-otomatisasi" sederhana. Seorang insinyur yang berkualifikasi masih diperlukan untuk operasi, tetapi sumber dayanya digunakan semata-mata untuk mengidentifikasi dan memecahkan masalah baru. Jika kita dengan kuat berpegang pada prinsip "seseorang seharusnya tidak menyelesaikan masalah yang diketahui", kita dapat mengasumsikan bahwa setelah beberapa waktu pasokan masalah yang tidak diketahui akan mulai mengering, dan fungsionalitas sistem yang dikembangkan akan mendekati AI untuk bidang aplikasi khusus ini.
Bagian terpenting dari sistem semacam itu adalah kategorisasi, identifikasi ulang anomali. Perusahaan kami sudah memiliki sistem serupa - Pelacak Pesanan, yang digunakan untuk memantau proses bisnis dari operator seluler yang mengelola pesanan. Pelacak Pesanan menganalisis ratusan peristiwa per detik, mengidentifikasi anomali, baik dalam baris terpisah maupun dalam kombinasi peristiwa, memungkinkan pengguna untuk mengelompokkannya, menetapkan nilai maksimum dan minimum, menentukan kesalahan pada berbagai tingkat keparahan, dan mengusulkan tindakan untuk menyelesaikan masalah. Sistem telah bekerja untuk waktu yang lama, banyak garu telah berhasil diselesaikan, jadi kami menganggapnya sebagai alat untuk kategorisasi.
Sekarang itu perlu untuk mengotomatisasi solusi masalah. Tidak seperti manajemen pesanan, di mana intervensi operator sering diperlukan (misalnya, ketika Anda perlu melibatkan departemen keuangan, layanan pelanggan, dll.), Kami memiliki kemampuan untuk secara otomatis menyelesaikan bagian penting dari insiden dan ada alat siap pakai untuk merancang solusi ini - skrip dari blok yang sudah jadi, yang dapat ditambah, diperluas logika, termasuk pemeriksaan tambahan dan kaitkan dengan masing-masing kategori kesalahan yang dikenali.
Apa yang bisa salah?
Itu saja!
Sistem pemantauan pesanan biasanya tidak memerlukan pengambilan keputusan dan koreksi dalam waktu nyata, dan anomali apa pun memengaruhi sejumlah kecil pelanggan, dari satu hingga beberapa ratus. Kami mencoba untuk memperkenalkan penanganan kesalahan otomatis pada proses yang mempengaruhi ratusan ribu dan jutaan pelanggan dan membutuhkan solusi secara real time atau dalam beberapa jam. Ini adalah risiko besar bagi operator mana pun yang bekerja dengan kami, dan, oleh karena itu, bagi kami, demi reputasi kami.
Kami harus secara signifikan meningkatkan fleksibilitas skrip, menerapkan sistem kontrol versi, menambahkan entitas "skrip contoh", yaitu, untuk setiap skrip sekarang Anda dapat membuat banyak subkelas dengan kombinasi parameter tertentu, ambang batas, pemeriksaan tambahan, dll. Saya harus meningkatkan fleksibilitas banyak tugas dengan memperkenalkan pemeriksaan tambahan parameter input dan output.
Arah pengembangan lainnya adalah meningkatkan rincian kategori acara yang dianalisis dan membuat meta-kategori, yaitu kombinasi berbagai peristiwa yang ditentukan oleh pengkategorisasi. Kami menambahkan perkiraan urutan anomali dan kebetulan anomali yang berbeda dalam waktu. Sistem menjadi semakin rumit, tetapi masih mempertahankan logika yang jelas - untuk setiap pasangan "kategori anomali - skenario yang dipilih", hubungan sebab akibat masih dipertahankan.
Untuk banyak kombinasi, kami telah memperoleh hasil yang andal dan andal serta merilisnya dengan cara yang produktif. Kesalahan, pencarian dan koreksi yang sebelumnya memakan waktu berjam-jam, sekarang diselesaikan dalam mode otomatis. Untuk jenis anomali lain, kami masih melanjutkan pengujian: di suatu tempat pada data pengujian, di suatu tempat dalam mode verifikasi manual dan konfirmasi skenario yang dipilih.
Dan ternyata ...
Kami baru-baru ini menyadari bahwa kami memperoleh hasil dari karya-karya ini yang tidak kami harapkan di awal - alat yang sangat efektif untuk merekayasa balik solusi orang lain, termasuk yang kami tidak memiliki dukungan pengembang, atau bahkan dokumentasi yang jelas. Secara tidak sengaja, apa yang disebut "penemuan proses bisnis" dilakukan. Kami belajar dalam praktik untuk menganalisis logika aplikasi, untuk mengidentifikasi kesalahan internal dan masalah integrasi dengan sistem lain. Sekarang kita tidak bisa hanya mengatur aplikasi orang lain - kita dapat mengembangkan perbaikan untuk mereka, meningkatkan integrasi, dan yang paling berharga adalah menawarkan produk kita untuk menggantikan warisan yang ada.
Pada tahap selanjutnya, kami ingin mencoba menerapkan solusi kami dalam bentuk produk komprehensif untuk pengujian integrasi, yang secara otomatis akan mendeteksi kesalahan dan anomali, belajar sambil jalan, menyediakan alat untuk koreksi gejala dan untuk mencari dan menganalisis masalah dalam logika aplikasi. Solusi ini akan memiliki efisiensi yang tidak kalah dari AIOps dan NoOps yang modis, sementara kami mempertahankan logika keputusan yang transparan dan mudah dikelola. Jadi, jika dalam beberapa tahun Anda menemukan solusi seperti itu dari Netcracker di pasaran, ingat - semuanya dimulai dengan skrip bash ...