Kita semua senang membicarakan kesuksesan kita dan tidak suka membicarakan kegagalan. Tetapi pengalaman kesalahan seringkali lebih berharga daripada keuntungan dari bisnis yang berhasil diselesaikan. Karena itu, saya hanya ingin membicarakan kasus-kasus seperti itu hari ini. Jadi ayo pergi ...
Panci, jangan masak!
Kisah ini terjadi beberapa tahun yang lalu, di awal karir saya sebagai pengembang 1C.
Sebuah proyek telah muncul di perusahaan kami untuk mengoptimalkan operasi satu pangkalan yang sangat sarat dari satu klien yang sangat besar dan dihormati. Klien dengan layanan keamanan paranoid sedemikian rupa sehingga tidak ada dan tidak mungkin ada akses jarak jauh ke server dari luar. Untuk terhubung ke pangkalan langsung ke kantor kami, jaringan area lokal yang terpisah dengan perangkat keras VPN dipasang dan workstation dengan perangkat lunak yang dinegosiasikan secara ketat diinstal. Tentu saja, tanpa hak administrator lokal.
Seperti proyek lain seperti ini, itu dimulai dengan pengumpulan data. Diasumsikan bahwa kita pertama-tama akan mengumpulkan berbagai indikator dalam satu bulan, dan kemudian kita akan terlibat dalam mengoptimalkan basis informasi itu sendiri. Bagaimana dan berapa banyak waktu dalam lingkungan birokrasi ini untuk mendirikan MCC, ini adalah bahan untuk cerita yang terpisah. Tetapi sekarang, pada beberapa titik, itu terjadi, MCC telah dikonfigurasi dan dimulai. Setelah itu, ahli yang melakukan proyek ini (Dima, hai!), Masuk ke mobil mewahnya dan pergi berkeliling negara kita yang luas, dan kemudian lebih ke negara-negara tetangga. Tapi kemudian, pada kenyataannya, saya masih tahu sedikit dan tahu caranya, tetapi saya sudah dianggap cukup pengembang. Karena itu, sebelum pergi, Dmitry menginstruksikan saya tugas yang sangat penting dan serius: 2 kali sehari, pada saat beban puncak, saya harus pergi ke komputer yang sangat rahasia itu dan memulai pengukuran di MCC, dan mematikannya setelah satu jam. Instruksi sangat sederhana dan jelas:
- Lihat, Anda menekan tombol hijau kecil ini "play", grafik berjalan berbeda, tunggu satu jam, lalu Anda tekan tombol ini - "stop". Itu saja.
Apa yang bisa lebih mudah, bukan? Sia-sia saya belajar selama 5 tahun di fakultas matematika?
Sepanjang minggu saya secara ketat mengamati ritual ini di pagi dan sore hari. Dan semuanya baik-baik saja sampai hari terakhir. Setelah makan siang, pada hari Jumat, seperti biasa, saya mulai mengumpulkan data, dan kemudian ... Ya, Anda tahu bagaimana itu terjadi ... Jumat, malam, kita perlu menyelesaikan beberapa hal yang mendesak, menyelesaikan beberapa tugas, setelah bekerja membawa istri saya ke ibu mertua saya, di sepanjang jalan jatuh ke satu toko, satu detik, dll. Secara umum, saya meninggalkan pekerjaan, benar-benar lupa tentang PKS malang ini.
Sabtu pagi dimulai dengan telepon. Kami mendapat SEMUA basis 1C-th di klien. Achtung dan bencana! Pakar kami berada di suatu tempat antara Dzheyrakh dan Pasanauri, di luar area akses jaringan. Admin utama klien juga di beberapa rumah negara dan tidak dapat diakses. Mencoba mencari tahu di telepon, apa alasannya? Entah bagaimana ternyata ruang disk sudah habis, sehingga layanan agen 1C bangkit. Di sini saya sudah mulai mencurigai sesuatu ...
Seperti yang Anda ingat, tidak ada udalenka. Komputer tidak hanya terisolasi dari Internet, tetapi juga di luar jaringan lokal kami. Tidak ada hubungannya - pergi bekerja. Saat mempersiapkan dan mengemudi, admin menyadari bahwa seluruh tempat diambil oleh log MCC dan melakukan apa yang menurut mereka paling masuk akal - mereka memotongnya melalui task manager. Silakan. Anda tidak bisa hanya menghapus log dari disk - kami akan kehilangan data pengukuran. Entah bagaimana mereka menemukan ruang yang cukup di jaringan berbagi dan menyalin file di sana. Pekerjaan tampaknya telah dilanjutkan.
Minggu pagi dimulai dengan telepon. Kami mendapat SEMUA basis 1C-th di klien. Achtung dan bencana mengambil dua! Semua kepanikan sudah berakhir - tempat sudah berakhir. Tapi bagaimana caranya? PKS dimatikan? Dengan tergesa-gesa, saya akan bekerja lagi, melempar log untuk membebaskan ruang. Dan mereka semua tumbuh dan tumbuh, terkutuklah mereka! Di bawah ketakutan akan eksekusi yang paling buruk, para administrator melarang saya untuk memulai sesuatu atau mengkonfigurasi apa pun. Untuk sisa hari Minggu, saya duduk di depan komputer dan menyalin log ke bola sehingga pangkalan tidak bangun lagi.
Baru larut malam Dima menghubungi dan mengatakan bahwa Anda hanya perlu menghapus satu file kecil di server 1C. Kemudian, beberapa minggu kemudian, saya membaca tentang dia dalam sebuah buku "meja" yang terkenal, tetapi pada hari itu, kelelahan, para tersiksa pulang untuk tidur.
Pada hari Senin pagi, akun kami diblokir sampai Dmitry kembali dari liburan, dan dikatakan dengan jelas ke akun saya: "Sehingga kami tidak akan melihatnya lagi!"
Ini adalah bagaimana proyek optimasi pertama saya berakhir untuk saya.
Dua kali dalam satu corong
Pegangan besar. 18 basis informasi dengan konfigurasi yang sama, berlokasi di seluruh negeri. Pembaruan berlangsung seminggu sekali dan merupakan ritual yang sama: file pengiriman harus disiapkan terlebih dahulu, diunggah ke cloud, pastikan sudah diunduh di semua cabang (bahkan pada 2018, di beberapa daerah Internet lebih lambat daripada 1C: ERP), periksa apakah cadangan dibuat di mana-mana (kami tampaknya tidak bertanggung jawab untuk ini, tetapi pengalaman pahit mengajarkan kami untuk aman), lalu di setiap cabang jalankan skrip pembaruan secara manual dan pastikan itu berfungsi tanpa kesalahan. Seringkali pada saat terakhir ditemukan bahwa satu tugas lagi harus dimasukkan dalam pengiriman dan ini adalah koreksi kecil, karena pembaruan berikutnya hanya dalam seminggu.
Jadi, itulah saatnya. Pengembang berpengalaman dengan pengalaman bertahun-tahun terburu-buru membuat kesalahan dalam satu baris saat mentransfer tugas ke sirkuit pertempuran. Kesalahan ternyata menjadi kritis, ditemukan setelah memperbarui semua database.
Nah apa yang harus dilakukan? Pengembang cepat memperbaiki kode. Jangan biarkan siapa pun menguji:
- Ya, ada sampah ... Saya tidak bisa membuat kesalahan dua kali dalam satu baris?
Satu jam kemudian, 18 cabang diperbarui untuk ketiga kalinya.
Pengembang yang bisa
Kisah tersebut diceritakan oleh seorang rekan di Skype.
[Rekan]: Suatu ketika ada "Pengembang yang bisa!" Dia memiliki pakaian pengembangan. Dia ingin membuka tes, tetapi gagal, dan membuka ...
[Rekan]: Tapi bisakah ini menghentikan "Pengembang yang bisa"? Tidak!
[I]: Dan ketika memperbarui, dia tidak mengerti bahwa ada orang-orang yang duduk di sana? )))
[Rekan]: Selain itu, ia melihat bahwa konf ada di dukungan ... Tapi apakah Anda pikir ini bisa menghentikan "Pengembang yang bisa"? Tidak!
[Kolega]: Dia menghapus konfigurasi dari dukungan (!) Dan menggergaji modnya melewati semua repositori ...
[I]: Bukan itu! Selesaikan ceritanya, pembaruan dinamis)))
[Kolega]: Pembaruan ... Sistem mengatakan: "Ada 18 sesi aktif dalam database!". Tapi bagaimana ini bisa menghentikan "Pengembang yang bisa"? Tidak dan tidak lagi!
[Kolega]: Dia memperbarui database dan meneruskan tugas ke tes ...
[Kolega]: Konsultan tidak dapat menemukan pakaian itu ... dan hanya setelah itu, dia menyadari bahwa dia ketinggalan.
[Kolega]: Saya harus memarahinya ...
[Rekan]: Saya memanggilnya ... dan saya tertawa di telepon ...
[Kolega]: Saya tidak mengerti ... BAGAIMANA ???
Keruntuhan transportasi
Kisah itu diceritakan oleh seorang rekan dan direkam dari kata-katanya.
Itu terjadi di perusahaan logistik besar. Sebagian besar proses bisnis terkonsentrasi dalam satu basis informasi. Pengguna kompetitif untuk 2012 - sekitar 3.000 orang dari semua wilayah di negara ini.
Tetapkan tugas sederhana. Menurutnya, ia membuat daftar informasi sendiri, di mana data ditulis ketika dokumen-dokumen tertentu diposkan. Meskipun tidak banyak jenis dokumen, jumlah dokumen ini per hari sangat besar. Secara teori, operasi tulis yang saya tambahkan ke register seharusnya tidak terlalu memuat sistem. Tetapi ada satu nuansa dalam pelaksanaan tugas - saat merekam satu set, properti Timpa diatur ke False. Artinya, setiap dokumen memegang entri yang ditambahkan ke register. Ini diperlukan sesuai dengan kondisi masalah, tetapi secara praktis tidak mempengaruhi kinerja, karena sesuai dengan kondisi pemilihan selalu ada 1-10 entri.
Pengujian fungsional berhasil. Kami melakukan beberapa dokumen, memastikan bahwa entri dalam register sudah benar, tidak melihat sesuatu yang mencurigakan dan mengirimkannya ke yang produktif.
Pada Jumat pagi yang malang itu, kami memperbarui pangkalan tempur, dan para pengguna mulai bekerja. 3000 orang dengan gembira mengisi dokumen dan register mulai diisi dengan data. Setelah memeriksa bahwa semuanya berjalan dengan baik, beberapa jam kemudian kami pulang dengan jiwa yang tenang (kami bekerja di zona waktu yang berbeda dengan pengguna utama basis informasi).
Perlu dicatat bahwa server yang menjalankan IS hampir merupakan salah satu yang paling kuat di Rusia yang digunakan di bawah 1C. Tetapi setelah beberapa jam "ada yang tidak beres" (c).
Pengguna mulai memperhatikan penurunan kinerja sistem. Semua operasi mulai melambat. Respons terhadap tindakan apa pun tumbuh lebih lama. Beban pada peralatan terus meningkat. Sementara departemen TI memahami apa yang sedang terjadi, pekerjaan dalam sistem hampir berhenti. Peralatan tidak dapat mengatasi, antrian pada disk lebih panjang daripada di kantor pos Rusia. Jika peralatan lebih lemah, masalah akan segera terdeteksi. Tetapi server yang paling kuat secara heroik menahan tangan saya yang bengkok selama setengah hari.
“Dari kata-kata” MSSQL, permintaan paling parah tiba-tiba menjadi permintaan baca di register saya. Meskipun saya tidak melakukan bacaan. Masalah dengan cepat ditemukan dalam kode 1C. Saya lupa mengatur pilihan pada set rekaman. Jika properti "Timpa" akan diatur ke "Benar", maka saya akan segera menemukan kesalahan, karena setiap entri akan menghapus seluruh register. Tetapi dalam kasus kami ini tidak terjadi. Pada contoh selusin dokumen, tentu saja, kami tidak melihat adanya kerugian kinerja. Tetapi ketika register mulai terisi dengan puluhan dan ratusan ribu baris - sistem setiap kali harus memeriksa seluruh register untuk catatan yang cocok.
Pada saat itu, menurut beberapa pengguna, keruntuhan transportasi sudah terjadi, karena mobil tidak menerima dokumen dari 1C dan tidak dapat meninggalkan titik bongkar.
Jadi, "hanya" lupa untuk menempatkan pilihan dalam recordset, saya menempatkan salah satu basis data 1C terbesar di Rusia.
PS Lihat juga: