Mulai tahun lalu, perusahaan kami mulai menyelenggarakan hackathon. Kompetisi pertama sangat sukses, kami menulisnya di . Hackathon kedua berlangsung pada Februari 2019 dan tak kalah suksesnya. Tentang tujuan diadakannya yang terakhir belum lama ini penyelenggara.
Para peserta diberi tugas yang cukup menarik dengan kebebasan penuh dalam memilih tumpukan teknologi untuk implementasinya. Penting untuk menerapkan platform pengambilan keputusan untuk kemudahan penerapan fungsi penilaian pelanggan yang dapat bekerja dengan aliran aplikasi yang cepat, menahan beban berat, dan sistem itu sendiri mudah diskalakan.
Tugas ini tidak sepele dan dapat diselesaikan dengan banyak cara, seperti yang kami yakini selama demonstrasi presentasi akhir proyek para peserta. Ada 6 tim yang terdiri dari 5 orang di hackathon, semua peserta memiliki proyek bagus, tetapi platform kami ternyata yang paling kompetitif. Kami memiliki proyek yang sangat menarik, yang ingin saya bicarakan di artikel ini.
Solusi kami adalah platform berbasis arsitektur Tanpa Server di dalam Kubernetes, yang mengurangi waktu yang diperlukan untuk menghadirkan fitur-fitur baru ke produksi. Hal ini memungkinkan analis untuk menulis kode di lingkungan yang nyaman bagi mereka dan menerapkannya ke dalam produksi tanpa partisipasi insinyur dan pengembang.
Apa yang mencetak gol
Tinkoff.ru, seperti banyak perusahaan modern, memiliki penilaian pelanggan. Scoring adalah sistem penilaian pelanggan berdasarkan metode statistik analisis data.
Misalnya, klien menghubungi kami dengan permintaan untuk memberinya pinjaman, atau membuka akun pengusaha perorangan dengan kami. Jika kita berencana memberikan pinjaman kepadanya, maka kita perlu menilai solvabilitasnya, dan jika rekening tersebut adalah pengusaha perorangan, maka kita perlu yakin bahwa klien tidak akan melakukan transaksi penipuan.
Dasar pengambilan keputusan tersebut adalah model matematika yang menganalisis data dari aplikasi itu sendiri dan data dari penyimpanan kami. Selain penilaian, metode statistik serupa juga dapat digunakan dalam menghasilkan rekomendasi individu untuk produk baru bagi klien kami.
Metode penilaian seperti ini dapat menerima berbagai masukan data. Dan pada titik tertentu kita dapat menambahkan parameter baru ke input, yang berdasarkan hasil analisis data historis, akan meningkatkan tingkat konversi penggunaan layanan.
Kami menyimpan banyak sekali data tentang hubungan pelanggan, dan volume informasi ini terus bertambah. Agar penilaian dapat berfungsi, pemrosesan data juga memerlukan aturan (atau model matematika) yang memungkinkan Anda dengan cepat memutuskan siapa yang akan menyetujui permohonan, siapa yang ditolak, dan siapa yang akan ditawarkan beberapa produk lagi, sambil menilai potensi minat mereka.
Untuk tugas yang ada, kami sudah menggunakan sistem pengambilan keputusan khusus , yang berdasarkan aturan yang ditetapkan oleh analis, teknolog, dan pengembang, memutuskan apakah akan menyetujui atau menolak produk perbankan tertentu kepada klien.
Ada banyak solusi siap pakai di pasar, baik model penilaian maupun sistem pengambilan keputusan itu sendiri. Kami menggunakan salah satu sistem ini di perusahaan kami. Namun bisnis semakin berkembang, terdiversifikasi, baik jumlah klien maupun jumlah produk yang ditawarkan semakin meningkat, dan seiring dengan itu, bermunculan ide-ide tentang bagaimana meningkatkan proses pengambilan keputusan yang ada. Tentunya orang yang bekerja dengan sistem yang ada memiliki banyak ide tentang bagaimana membuatnya lebih sederhana, lebih baik, lebih nyaman, namun terkadang ide dari luar berguna. Hackathon Baru diselenggarakan dengan tujuan mengumpulkan ide-ide yang masuk akal.
Tugas
Hackathon diadakan pada tanggal 23 Februari. Para peserta ditawari tugas tempur: mengembangkan sistem pengambilan keputusan yang harus memenuhi sejumlah syarat.
Kami diberitahu bagaimana sistem yang ada berfungsi dan kesulitan apa yang timbul selama pengoperasiannya, serta tujuan bisnis apa yang harus dicapai oleh platform yang dikembangkan. Sistem harus memiliki waktu pemasaran yang cepat untuk mengembangkan aturan sehingga kode kerja analis dapat diproduksi secepat mungkin. Dan untuk aliran lamaran yang masuk, waktu pengambilan keputusan harus cenderung minimal. Selain itu, sistem yang dikembangkan harus memiliki kemampuan cross-sell agar dapat memberikan kesempatan kepada klien untuk membeli produk perusahaan lain jika disetujui oleh kami dan mempunyai potensi minat dari klien.
Jelas bahwa tidak mungkin untuk menulis proyek siap rilis dalam semalam yang pasti akan masuk ke produksi, dan cukup sulit untuk mencakup keseluruhan sistem, jadi kami diminta untuk mengimplementasikan setidaknya sebagian darinya. Sejumlah persyaratan ditetapkan yang harus dipenuhi oleh prototipe. Dimungkinkan untuk mencoba mencakup semua persyaratan secara keseluruhan, dan bekerja secara rinci pada masing-masing bagian platform yang sedang dikembangkan.
Sedangkan untuk teknologi, seluruh peserta diberikan kebebasan penuh untuk memilih. Konsep dan teknologi apa pun dapat digunakan: Streaming data, pembelajaran mesin, sumber peristiwa, data besar, dan lainnya.
Solusi kami
Setelah sedikit bertukar pikiran, kami memutuskan bahwa solusi FaaS akan ideal untuk menyelesaikan tugas tersebut.
Untuk solusi ini, perlu ditemukan kerangka Serverless yang sesuai untuk mengimplementasikan aturan sistem pengambilan keputusan yang sedang dikembangkan. Karena Tinkoff secara aktif menggunakan Kubernetes untuk manajemen infrastruktur, kami melihat beberapa solusi siap pakai berdasarkan Kubernetes; saya akan memberi tahu Anda lebih banyak tentangnya nanti.
Untuk menemukan solusi yang paling efektif, kami melihat produk yang sedang dikembangkan dari sudut pandang penggunanya. Pengguna utama sistem kami adalah analis yang terlibat dalam pengembangan aturan. Aturan harus diterapkan ke server, atau, seperti dalam kasus kami, diterapkan di cloud, untuk pengambilan keputusan selanjutnya. Dari sudut pandang analis, alur kerjanya terlihat seperti ini:
- Analis menulis skrip, aturan, atau model ML berdasarkan data dari gudang. Sebagai bagian dari hackathon, kami memutuskan untuk menggunakan Mongodb, namun pilihan sistem penyimpanan data tidak penting di sini.
- Setelah menguji aturan yang dikembangkan pada data historis, analis mengunggah kodenya ke panel admin.
- Untuk memastikan pembuatan versi, semua kode akan masuk ke repositori Git.
- Melalui panel admin dimungkinkan untuk menyebarkan kode di cloud sebagai modul Tanpa Server yang berfungsi terpisah.
Data awal dari klien harus melewati layanan Pengayaan khusus yang dirancang untuk memperkaya permintaan awal dengan data dari gudang. Penting untuk mengimplementasikan layanan ini sedemikian rupa sehingga dapat bekerja dengan satu repositori (dari mana analis mengambil data saat mengembangkan aturan) untuk mempertahankan struktur data terpadu.
Bahkan sebelum hackathon, kami memutuskan kerangka kerja Tanpa Server yang akan kami gunakan. Saat ini terdapat cukup banyak teknologi di pasaran yang menerapkan pendekatan ini. Solusi paling populer dalam arsitektur Kubernetes adalah Fission, Open FaaS, dan Kubeless. Bahkan ada .
Setelah mempertimbangkan semua pro dan kontra, kami memilih . Kerangka kerja Tanpa Server ini cukup mudah untuk dikelola dan memenuhi persyaratan tugas.
Untuk bekerja dengan Fission, Anda perlu memahami dua konsep dasar: fungsi dan lingkungan. Fungsi adalah sepotong kode yang ditulis dalam salah satu bahasa yang memiliki lingkungan Fission. termasuk Python, JS, Go, JVM dan banyak bahasa dan teknologi populer lainnya.
Fission juga mampu menjalankan fungsi yang dibagi menjadi beberapa file, yang telah dikemas sebelumnya menjadi arsip. Pengoperasian Fission di cluster Kubernetes dijamin oleh pod khusus, yang dikelola oleh framework itu sendiri. Untuk berinteraksi dengan pod cluster, setiap fungsi harus diberi rutenya sendiri, dan ke sana Anda dapat meneruskan parameter GET atau isi permintaan jika ada permintaan POST.
Hasilnya, kami berencana untuk mendapatkan solusi yang memungkinkan analis menerapkan skrip aturan yang dikembangkan tanpa partisipasi insinyur dan pengembang. Pendekatan yang dijelaskan juga menghilangkan kebutuhan pengembang untuk menulis ulang kode analis ke bahasa lain. Misalnya, untuk sistem pengambilan keputusan yang kami gunakan saat ini, kami harus menulis aturan dalam teknologi dan bahasa yang sangat terspesialisasi, yang cakupannya sangat terbatas, dan juga terdapat ketergantungan yang kuat pada server aplikasi, karena semua rancangan peraturan bank dikerahkan dalam satu lingkungan. Akibatnya, untuk menerapkan aturan baru, seluruh sistem perlu dirilis.
Dalam solusi yang kami usulkan, tidak perlu merilis aturan; kode dapat dengan mudah diterapkan hanya dengan mengklik tombol. Selain itu, manajemen infrastruktur di Kubernetes memungkinkan Anda untuk tidak memikirkan beban dan penskalaan; masalah seperti itu dapat diselesaikan dengan sendirinya. Dan penggunaan gudang data tunggal menghilangkan kebutuhan untuk membandingkan data real-time dengan data historis, sehingga menyederhanakan pekerjaan analis.
Apa yang kami dapatkan
Karena kami datang ke hackathon dengan solusi siap pakai (dalam fantasi kami), yang harus kami lakukan hanyalah mengubah semua pemikiran kami menjadi baris kode.
Kunci sukses di setiap hackathon adalah persiapan dan rencana yang ditulis dengan baik. Oleh karena itu, hal pertama yang kami lakukan adalah memutuskan modul apa yang akan terdiri dari arsitektur sistem kami dan teknologi apa yang akan kami gunakan.
Arsitektur proyek kami adalah sebagai berikut:
Diagram ini menunjukkan dua titik masuk, analis (pengguna utama sistem kami) dan klien.
Proses kerjanya terstruktur seperti ini. Analis mengembangkan fungsi aturan dan fungsi pengayaan data untuk modelnya, menyimpan kodenya di repositori Git, dan menyebarkan modelnya ke cloud melalui aplikasi administrator. Mari kita pertimbangkan bagaimana fungsi yang diterapkan akan dipanggil dan membuat keputusan atas permintaan masuk dari klien:
- Klien mengisi formulir di situs web dan mengirimkan permintaannya ke pengontrol. Aplikasi yang memerlukan pengambilan keputusan masuk ke input sistem dan dicatat dalam database dalam bentuk aslinya.
- Selanjutnya, permintaan mentah dikirim untuk pengayaan, jika perlu. Anda dapat melengkapi permintaan awal dengan data baik dari layanan eksternal maupun dari penyimpanan. Kueri yang diperkaya yang dihasilkan juga disimpan dalam database.
- Fungsi analis diluncurkan, yang mengambil kueri yang diperkaya sebagai masukan dan menghasilkan solusi, yang juga ditulis ke penyimpanan.
Kami memutuskan untuk menggunakan MongoDB sebagai penyimpanan di sistem kami karena penyimpanan data berorientasi dokumen dalam bentuk dokumen JSON, karena layanan pengayaan, termasuk permintaan asli, mengumpulkan semua data melalui pengontrol REST.
Jadi, kami punya waktu XNUMX jam untuk mengimplementasikan platform tersebut. Kami mendistribusikan peran dengan cukup sukses, setiap anggota tim memiliki area tanggung jawabnya sendiri dalam proyek kami:
- Panel admin front-end untuk pekerjaan analis, yang melaluinya ia dapat mengunduh aturan dari sistem kontrol versi skrip tertulis, memilih opsi untuk memperkaya data masukan, dan mengedit skrip aturan secara online.
- Admin backend, termasuk REST API untuk bagian depan dan integrasi dengan VCS.
- Menyiapkan infrastruktur di Google Cloud dan mengembangkan layanan untuk memperkaya sumber data.
- Modul untuk mengintegrasikan aplikasi admin dengan kerangka kerja Tanpa Server untuk penerapan aturan selanjutnya.
- Skrip aturan untuk menguji kinerja seluruh sistem dan agregasi analitik pada aplikasi yang masuk (keputusan dibuat) untuk demonstrasi akhir.
Mari kita mulai.
Frontend kami ditulis dalam Angular 7 menggunakan UI Kit perbankan. Versi terakhir dari panel admin terlihat seperti ini:
Karena waktu yang tersedia terbatas, kami mencoba menerapkan fungsi utama saja. Untuk menerapkan suatu fungsi di kluster Kubernetes, penting untuk memilih peristiwa (layanan yang aturannya perlu diterapkan di cloud) dan kode fungsi yang mengimplementasikan logika pengambilan keputusan. Untuk setiap penerapan aturan untuk layanan yang dipilih, kami menulis log peristiwa ini. Di panel admin Anda dapat melihat log semua peristiwa.
Semua kode fungsi disimpan dalam repositori Git jarak jauh, yang juga harus diatur di panel admin. Untuk membuat versi kode, semua fungsi disimpan di berbagai cabang repositori. Panel admin juga menyediakan kemampuan untuk melakukan penyesuaian pada skrip tertulis, sehingga sebelum menerapkan fungsi ke produksi, Anda tidak hanya dapat memeriksa kode tertulis, tetapi juga membuat perubahan yang diperlukan.
Selain fungsi aturan, kami juga menerapkan kemampuan untuk memperkaya data sumber secara bertahap menggunakan fungsi Pengayaan, yang kodenya juga berupa skrip yang memungkinkan untuk masuk ke gudang data, memanggil layanan pihak ketiga, dan melakukan penghitungan awal. . Untuk mendemonstrasikan solusi kami, kami menghitung tanda zodiak klien yang meninggalkan permintaan dan menentukan operator selulernya menggunakan layanan REST pihak ketiga.
Backend platform ditulis dalam Java dan diimplementasikan sebagai aplikasi Spring Boot. Awalnya kami berencana menggunakan Postgres untuk menyimpan data admin, namun, sebagai bagian dari hackathon, kami memutuskan untuk membatasi diri pada H2 sederhana untuk menghemat waktu. Di backend, integrasi dengan Bitbucket diterapkan untuk membuat versi fungsi pengayaan kueri dan skrip aturan. Untuk integrasi dengan repositori Git jarak jauh, kami menggunakan , yang merupakan semacam pembungkus perintah CLI, memungkinkan Anda menjalankan instruksi git apa pun menggunakan antarmuka perangkat lunak yang nyaman. Jadi kami memiliki dua repositori terpisah untuk fungsi dan aturan pengayaan, dan semua skrip dibagi ke dalam direktori. Melalui UI, dimungkinkan untuk memilih penerapan skrip terbaru dari cabang repositori yang berubah-ubah. Saat membuat perubahan pada kode melalui panel admin, penerapan kode yang diubah dibuat di repositori jarak jauh.
Untuk mengimplementasikan ide kami, kami membutuhkan infrastruktur yang sesuai. Kami memutuskan untuk menerapkan cluster Kubernetes kami di cloud. Pilihan kami adalah Google Cloud Platform. Kerangka kerja tanpa server Fission diinstal pada kluster Kubernetes, yang kami terapkan di Gcloud. Awalnya, layanan pengayaan data sumber diimplementasikan sebagai aplikasi Java terpisah yang dibungkus dalam sebuah Pod di dalam cluster k8s. Namun setelah demonstrasi awal proyek kami di tengah hackathon, kami disarankan untuk membuat layanan Pengayaan lebih fleksibel untuk memberikan kesempatan memilih cara memperkaya data mentah aplikasi yang masuk. Dan kami tidak punya pilihan selain menjadikan layanan pengayaan juga Tanpa Server.
Untuk bekerja dengan Fission, kami menggunakan Fission CLI, yang harus diinstal di atas Kubernetes CLI. Menerapkan fungsi ke dalam kluster k8s cukup sederhana; Anda hanya perlu menetapkan rute internal dan masuk ke fungsi tersebut untuk mengizinkan lalu lintas masuk jika akses di luar kluster diperlukan. Menyebarkan satu fungsi biasanya membutuhkan waktu tidak lebih dari 10 detik.
Presentasi akhir proyek dan kesimpulannya
Untuk mendemonstrasikan cara kerja sistem kami, kami telah menempatkan formulir sederhana di server jarak jauh tempat Anda dapat mengirimkan aplikasi untuk salah satu produk bank. Untuk meminta, Anda harus memasukkan inisial Anda, tanggal lahir dan nomor telepon.
Data dari formulir klien masuk ke pengontrol, yang secara bersamaan mengirimkan permintaan untuk semua aturan yang tersedia, setelah sebelumnya memperkaya data sesuai dengan kondisi yang ditentukan, dan menyimpannya di penyimpanan umum. Secara total, kami menerapkan tiga fungsi yang mengambil keputusan pada aplikasi masuk dan 4 layanan pengayaan data. Setelah mengirimkan aplikasi, klien menerima keputusan kami:
Selain penolakan atau persetujuan, klien juga menerima daftar produk lain, permintaan yang kami kirimkan secara paralel. Inilah cara kami mendemonstrasikan kemungkinan penjualan silang di platform kami.
Total ada 3 produk bank fiktif yang tersedia:
- Kredit.
- Toy
- Hipotek.
Selama demonstrasi, kami menerapkan fungsi yang telah disiapkan dan skrip pengayaan untuk setiap layanan.
Setiap aturan memerlukan kumpulan data masukannya sendiri. Jadi, untuk menyetujui hipotek, kami menghitung tanda zodiak klien dan menghubungkannya dengan logika kalender lunar. Untuk menyetujui mainan tersebut, kami memeriksa bahwa klien telah mencapai usia dewasa, dan untuk mengeluarkan pinjaman, kami mengirimkan permintaan ke layanan terbuka eksternal untuk menentukan operator seluler, dan keputusan dibuat mengenai hal itu.
Kami mencoba membuat demonstrasi kami menarik dan interaktif, semua orang yang hadir dapat membuka formulir kami dan memeriksa ketersediaan layanan fiksi kami kepada mereka. Dan di akhir presentasi, kami mendemonstrasikan analisis aplikasi yang diterima, yang menunjukkan berapa banyak orang yang menggunakan layanan kami, jumlah persetujuan dan penolakan.
Untuk mengumpulkan analitik secara online, kami juga menerapkan alat BI sumber terbuka dan mengencangkannya ke unit penyimpanan kami. Metabase memungkinkan Anda membuat layar dengan analitik pada data yang kami minati; Anda hanya perlu mendaftarkan koneksi ke database, memilih tabel (dalam kasus kami, pengumpulan data, karena kami menggunakan MongoDB), dan menentukan bidang yang kami minati .
Hasilnya, kami mendapatkan prototipe platform pengambilan keputusan yang bagus, dan selama demonstrasi, setiap pendengar dapat secara pribadi memeriksa kinerjanya. Solusi yang menarik, prototipe yang telah selesai, dan demonstrasi yang sukses memungkinkan kami untuk menang, meskipun ada persaingan yang kuat dari tim lain. Saya yakin artikel menarik juga bisa ditulis di proyek masing-masing tim.
Sumber: www.habr.com