“Besok adalah tanggal 20, yang berarti akan ada badai lagi. Tidak mungkin untuk menghentikannya, hanya bersiap dan berharap bahwa kali ini akan meledak, keajaiban akan terjadi, dan feri danau kita akan menaklukkan lautan .
" Pemikiran seperti itu mengalahkan tim yang terlibat dalam mendukung portal layanan kota beberapa tahun yang lalu. Bagaimana kita masuk ke dalam situasi ini dan bagaimana kita menemukan jalan keluar akan dijelaskan di bawah ini.
Bagaimana semuanya dimulai
Pada tahun 1990-an yang jauh, sektor perumahan dan utilitas mengalami booming dalam pengembangan, teknologi baru diperkenalkan, sistem informasi otomatis, dan peralatan baru dibeli. Tetapi sesuatu tetap untuk waktu yang lama praktis tidak berubah, yaitu pembayaran untuk apartemen. Ya, kwitansi yang sama untuk apartemen itu, setelah diubah menjadi dokumen pembayaran, setelah mendapatkan barcode, dekripsi terperinci, tetap sebagai potongan kertas. Skema khas pekerjaan pusat penyelesaian perumahan dan perusahaan jasa komunal atau perusahaan penyedia sumber daya adalah sebagai berikut:
Secara bertahap, Internet modem digantikan oleh akses broadband, timbul pemikiran - mengapa tidak menerima dokumen pembayaran online dalam bentuk elektronik? Pada saat yang sama, sektor layanan perumahan dan komunal berguncang dalam bentuk organisasi, MPP perumahan dan layanan komunal (perusahaan produksi kota layanan perumahan dan komunal) digantikan oleh perusahaan unit kota (perusahaan unit kota), DEZs (direktorat dari satu pelanggan). Sebagai hasil dari semua transformasi, departemen TI dari perusahaan perumahan dan layanan komunal teralienasi, dan berbagai pusat pemukiman lahir berdasarkan basis mereka. Inti dari pusat permukiman adalah, pada kenyataannya, perhitungan sewa dan dukungan informasi dari populasi.
Tahap Pertumbuhan, 00-an
Saat itulah portal informasi pertama lahir yang menyediakan populasi dengan layanan elektronik. Jumlah pengguna pertama diukur dalam lusinan, tidak semua orang memercayai dokumen pembayaran elektronik, yang lain belum pernah mendengar inovasi, aplikasi mobile di bidang layanan publik jarang. Pekerjaan portal informasi tidak jauh berbeda dari pekerjaan sistem informasi yang sudah dikenal dan, tentu saja, tidak pernah menjadi arsitektur yang tinggi.
Tahun-tahun berlalu, portal membaik, ada peluang untuk mengambil pembacaan perangkat pengukuran, menghasilkan sertifikat, dll. Pada saat itulah "awan" pertama muncul di cakrawala, semakin banyak pengguna mulai mendaftar di portal dan meminta data. Di kejauhan, gelombang pertama dari beban yang mendekat muncul.
Tim (selanjutnya disebut Tim 1) mengambil langkah-langkah optimasi berikut:
- Mengubah ukuran dokumen pembayaran dalam PDF dari 0,5MB menjadi 0,2MB
- Membuat antrian untuk pembentukan dokumen pembayaran
- Penyimpanan dokumen pembayaran yang dihasilkan untuk permintaan berulang
- Membuat replika database utama, hanya untuk kebutuhan portal
Selama beberapa tahun, situasinya tampak stabil, jumlah pengguna portal individu diukur dalam ribuan, belum menyerbu, tetapi mengguncang secara signifikan, desentralisasi pusat kliring memainkan ke tangan pengembang.
Tahap Lompat Besar
Tonggak baru dalam sejarah adalah pengembangan portal layanan kota di tingkat regional. Dimasukkannya satu titik masuk tunggal untuk setiap penduduk republik adalah ide yang menggoda, di samping itu, ini akan meningkatkan peringkat situs negara ke tingkat situs komersial atau perbankan terbaik, di mana setiap penduduk wilayah akan menerima berbagai jenis layanan. Salah satu yang paling populer adalah pembayaran perumahan dan layanan komunal dan dimasukkannya pembacaan meter.
Dengan demikian, langkah selanjutnya adalah pemisahan informasi operasional pusat penyelesaian dari informasi yang ditampilkan dalam dokumen pembayaran. Untuk ini, format transfer data sederhana dan database untuk menyimpan informasi dikembangkan, dan perhitungan ruang yang diperlukan untuk penyimpanan selama 5 tahun operasi dilakukan.
Keputusan penting yang dibuat pada tahap ini:
- Bagian informasi departemen dari basis data operasional;
- Pengembangan database untuk menyimpan format ini;
- Menggabungkan data pusat-pusat pemukiman di daerah-daerah ke dalam satu basis data tunggal;
- Integrasi dengan proses portal, pengembangan layanan.
Pada tahap ini, solusinya berubah dari full-fledged menjadi backend, karena portal menyediakan pengguna dengan satu antarmuka. Portal memiliki timnya sendiri, yang mengembangkannya terlepas dari solusi saat ini dari pusat pemukiman. Dalam sejarah kami,
tim kedua muncul
(selanjutnya disebut Tim 2) dan vendor baru. Seperti yang akan kita lihat nanti, ini telah secara signifikan mempengaruhi pengembangan dan penyelesaian masalah. Inti dari solusi desain adalah sebagai berikut:
Ketika merancang basis data, pemetaan sederhana format ke basis data diterima, PostgreSQL 9.3 dipilih sebagai DBMS (pada waktu itu versi yang sangat terkini). Format ini terdiri dari 9 file datar, yang masing-masing dimuat dengan perintah COPY (kita baca - sangat cepat) ke dalam banyak tabel pusat penyelesaian tertentu (setiap pusat penyelesaian memiliki nomor registrasi sendiri) dari database portal. Di beberapa pusat penyelesaian, jumlah catatan yang diperlukan untuk pembentukan dokumen pembayaran mencapai 1.000.000. Dalam setahun ini berjumlah 12.000.000, lebih dari 5 tahun -60.000.000. Jumlah permintaan ke basis data ini meningkat menjadi jumlah semua pengguna portal distrik dan dapat membuat puluhan ribu. Ada sesuatu untuk dipikirkan.
Karena tidak memiliki pengalaman seperti itu,
Tim 1 mengambil langkah-langkah berikut untuk mengurangi potensi muatan:
- Tabel dibagi oleh pusat pemukiman dan bulan partisi;
- Proses pemuatan data diberi jarak waktu untuk berbagai pusat penagihan.
Masalah pertumbuhan
Portal diluncurkan, dan rencana yang disiapkan dihadapkan dengan kenyataan:
- Jumlah pengguna melebihi perkiraan dengan sangat cepat.
- Kueri pergi ke tabel master, tetapi DBMS masih mensurvei semua tabel
- Pemuatan palsu di server database. Di server ini ada yang lain, basis data yang sangat besar, informasi yang datang secara acak, memuatnya mengambil semua sumber daya yang tersedia
- Layanan pembentukan dokumen pembayaran melambat karena implementasi yang tidak efisien
- Beban dari pengguna tidak didistribusikan secara merata sepanjang bulan, tetapi terkonsentrasi dalam dua periode:
Momen ini dideskripsikan di awal tulisan. Sulit untuk mendiagnosis masalahnya, karena masalah itu tampak di semua tempat sekaligus. Tim 1 dan Tim 2, yang sama-sama dicintai oleh kepemimpinan mereka, mengambil langkah untuk keluar dari situasi ini, tetapi praktis tidak ada komunikasi di antara mereka sendiri:
Tim 2 , tampaknya, mengambil langkah logis dan berguna: pembentukan dokumen pembayaran mulai diminta segera setelah pengguna memasuki sistem, dengan harapan bahwa ketika ia mencapai halaman di halaman, AP sudah terbentuk, dan dokumen yang sudah selesai dapat ditarik dengan cepat.
Pada saat ini,
Tim 1 secara heroik menyelesaikan satu masalah per bulan setiap bulan, setiap kali meyakinkan pelanggan bahwa di sanalah akar masalah bersembunyi:
- SQL yang Dioptimalkan (menerima peningkatan kinerja sewaktu-waktu);
- Memisahkan server basis data untuk portal dari sisa basis data;
- Kami melakukan pembentukan dokumen pembayaran dalam aplikasi terpisah dan juga mengoptimalkannya;
- Kami merevisi banding ke tabel utama, mengubah versi PostgreSQL;
- Sekali lagi, kami merevisi banding (sekarang hanya 1 partisi tertentu yang diminta dari tabel utama - bahkan akselerasi kadang-kadang).
Upaya heroik dari tim-tim tersebut membawa keberhasilan lokal (selama 2-3 bulan tampaknya masalahnya telah terpecahkan). Namun kenyataan selalu memunculkan catatan pengantar baru:
- Basis data telah berisi beberapa tahun dan telah berkembang lebih dari 1 TB;
- Jumlah pengguna sudah ratusan ribu.
Sementara perjuangan sedang berlangsung,
Tim 2 menyiapkan tes layanan otomatis, sehingga masalah kinerja diketahui dalam hitungan menit dan masalah tersebut meningkat ke tingkat kontrol tertinggi secara otomatis melalui email.
Saat ini di
Tim 1 :
- Waktu pengarsipan basis data mulai melampaui batas yang diizinkan (layanan menjadi tidak tersedia);
- Satu panggilan ke layanan segera mempengaruhi berbulan-bulan, masing-masing, menghasilkan banyak permintaan;
- DBMS menjadi lebih buruk dalam memenuhi permintaan karena peningkatan jumlah tabel (partisi);
- Pengguna yang hanya ingin melakukan pembacaan instrumen masih meminta pembentukan dokumen pembayaran (ingat keputusan Tim 2).
Menjadi jelas bahwa, dari sudut pandang teknis, solusi telah mencapai batasnya dan sudah waktunya untuk mulai menganalisis perilaku pengguna untuk mengoptimalkan proses atau mengubah teknologi secara radikal.
Sebagai hasil dari analisis (di sini adalah topik untuk artikel terpisah), tindakan berikut diambil:
- Data terputus hingga 3 tahun terakhir, karena tidak ada panggilan pada periode sebelumnya; sejak itu periode lama telah terputus setiap tahun;
- Kami mengembalikan banding ke tabel master untuk merujuk ke partisi tertentu secara langsung (mengurangi beban pada DBMS).
Hadir
Sekarang sistem ini cukup stabil, sesuai dengan kerangka waktu pengaturan dan persyaratan untuk karakteristik non-fungsional, tetapi awan kembali muncul di cakrawala:
- Peningkatan lebih lanjut dalam jumlah pengguna;
- Pertumbuhan jumlah rumah tangga yang dilayani;
- Meningkatkan kompleksitas layanan yang disediakan;
- Peningkatan granularitas data tersedia bagi pengguna.
Oleh karena itu, sebuah rencana disusun dan implementasi dari langkah-langkah berikut sedang dipersiapkan:
- Analisis perilaku pengguna: berapa banyak dari mereka yang benar-benar melihat dokumen pembayaran, dan berapa banyak yang membayar jumlahnya, seperti untuk ponsel;
- Pembentukan awal dokumen pembayaran untuk pengguna yang biasanya melihat dokumen pembayaran pada saat pemuatan terendah;
- Transisi ke teknologi alternatif (ya, banyak dari mereka yang mencapai titik ini memiliki solusi yang jauh lebih maju yang menyelesaikan semua masalah pada awalnya, pada sumber daya ponsel).
Tampaknya ini dapat menempatkan titik optimis yang besar. Semua dilakukan dengan baik: mereka yang melakukannya dan mereka yang akan melakukannya dengan lebih baik segera. Tapi besok akan ada proyek Highload baru, masalah asing baru. Bagaimana mempersiapkan mereka sekarang, apa yang bisa dipertimbangkan ketika belum ada data?
Pendekatan sistematis untuk memecahkan masalah
Bisakah kita mengubah pengalaman menjadi metodologi untuk mendekati masalah dalam proyek-proyek Highload? Anehnya, jawabannya adalah YA, semuanya telah ditemukan untuk kita dan berada dalam kerangka kerja
Theory of Constraint TOC . Hanya 5 langkah sederhana:
- Temukan batasan sistem.
- Putuskan bagaimana memanfaatkan batasan sistem secara maksimal.
- Bawalah segala hal lainnya ke keputusan ini.
- Perluas batasan sistem.
- PERHATIAN! Jika pembatasan telah dihapus dalam 4 langkah sebelumnya, kembali ke langkah 1, tetapi jangan biarkan inersia menyebabkan pembatasan sistem.
Deskripsi teori ini dan esensi langkah-langkahnya dijelaskan dengan sangat baik dalam literatur di akhir artikel, tetapi saya akan menulis visi saya dalam kerangka proses saat ini:
- Pembatasan: waktu pembentukan dokumen pembayaran.
- Solusi: Hasilkan semua dokumen pembayaran di muka, saat mengunduh data.
- Bawahan keputusan: Saat menghubungi pengguna, terbitkan dokumen yang sudah jadi.
- Perpanjang pembatasan: Optimalkan waktu untuk pembentukan dokumen pembayaran.
- Abaikan sistem pra-formasi untuk SEMUA rumah tangga, tentukan batasan baru.
Pendekatan semacam itu akan mengurangi waktu solusi beberapa tahun, dengan biaya tenaga kerja minimum untuk programmer. Pos menunjukkan jauh dari semua masalah yang muncul dan tidak ada beberapa detail dari solusi, karena mereka tidak begitu signifikan dalam pendekatan yang diusulkan.
Apa yang harus dibaca pada topik:
- “Tujuannya. Proses Peningkatan Berkesinambungan, ” Eliyahu Goldratt
- "Teori Kendala. Pendekatan dasar, alat, dan solusi ” , Dmitry Egorov
- “Teori Kendala Goldratt. Pendekatan Sistem untuk Peningkatan Berkesinambungan, ” William Detmer