Kembali pada Masa yang Tidak Diketahui Siapapun

Bab 10

Saya pernah mendengar kata-kata serupa ketika smartphone pertama kali diluncurkan.

Bahwa dunia akan berubah.

Pada awalnya, saya pikir itu sedikit berlebihan.

Saya pikir bahkan jika menggunakan internet di ponsel, itu hanya layar kecil. Menurut saya, itu hanya versi yang lebih tidak nyaman dari apa yang kami lakukan di PC.

Namun, tidak lama kemudian, banyak hal benar-benar berubah.

Ketika membuat antarmuka web, kami harus mempertimbangkan mobile secara terpisah, dan profesi pengembang aplikasi secara alami muncul. Perusahaan tiba-tiba mulai berbicara tentang strategi mobile, dan sistem yang ada memerlukan API baru.

Saya juga tidak berada di pusat hal-hal yang baru saat itu.

Seseorang membuat aplikasi, dan seseorang merancang struktur layanan mobile.

Saya menghubungkan sistem yang ada.

Ketika pesanan masuk dari mobile, saya mengirimnya ke sistem pesanan yang ada, membuat informasi anggota yang ada dapat digunakan di aplikasi, dan memastikan sistem pembayaran dan sistem poin berfungsi dengan baik di mobile juga.

Di balik antarmuka baru ada sistem lama.

Dan sistem lama itu tidak berubah semudah yang saya bayangkan.

Sekali, ada masalah dalam proyek pesanan mobile.

Pesanan yang berfungsi baik dalam pengujian tiba-tiba gagal secara sporadis di lingkungan produksi.

Aplikasi menunjukkan pembayaran selesai, tetapi pesanan tidak tercipta.

Pada awalnya, semua orang mencurigai pihak mobile.

"Bukankah permintaan dari aplikasi dikirim dua kali?"

"Bukankah itu menghubungi kembali jika jaringan terputus?"

Saya melihat log.

Aplikasi memanggil hanya sekali dengan normal.

Permintaan juga masuk di server.

Dari sana, semuanya aneh.

Sebelum menyimpan pesanan, kami menunggu respons dari sistem eksternal tertentu.

Kadang-kadang respons itu terlambat.

Ketika waktu habis terjadi, seluruh transaksi pesanan dibatalkan.

Masalahnya adalah pembayaran sudah selesai sebelumnya.

Rapat diadakan.

Pengembang mobile.

Pengembang pesanan.

Penanggung jawab pembayaran.

Penanggung jawab vendor eksternal.

Semua orang mengatakan sistem mereka normal.

Apa yang mereka katakan tidak salah.

Jika masing-masing melihat bagian mereka saja, itu benar.

Saya menggambar alurnya di papan tulis.

Aplikasi.

API.

Pembayaran.

Pesanan.

Sistem eksternal.

Saya menggambar panah satu demi satu.

"Pembayaran berakhir di sini."

Saya menunjuk kotak berikutnya dengan jari saya.

"Kami menunggu di sini sebelum menyimpan pesanan."

Seseorang berkata.

"Apakah itu semula dipanggil sebelum pesanan?"

"Itu terjadi di PC."

"Tidak ada masalah di PC."

"Kondisi jaringan mobile berbeda."

"Sistem eksternal sama."

Saya berpikir sebentar.

"Volume permintaan mungkin telah berubah."

Ruang rapat menjadi senyap.

Traffic meningkat setelah layanan mobile dimulai.

Di PC, pengguna secara alami membutuhkan waktu saat berpindah layar, tetapi di aplikasi prosesnya lebih cepat. Konsentrasi permintaan pada waktu tertentu juga berbeda.

Struktur lama itu menyebabkan masalah dalam cara penggunaan baru.

Akhirnya saya mengubah alur pesanan.

Setelah pembayaran selesai, saya menyimpan pesanan terlebih dahulu, dan menangani sistem eksternal secara terpisah.

Mengatakan bahwa mudah saja.

Mengubahnya dalam praktik membutuhkan waktu yang cukup lama.

Ketika saya menyentuh logika yang ada, masalah timbul di tempat lain.

Batch lama memantau nilai status itu, layar admin juga menggunakan nilai yang sama, dan program settlement juga terhubung.

Ketika mengubah satu, tiga hal lain mengikuti.

Setiap kali melakukan pekerjaan seperti itu, saya mengambil peran yang serupa.

"Silakan cari tahu ke mana pengaruhnya jika mengubah ini."

"Silakan periksa mengapa logika lama seperti ini."

"Ada data aneh dari sisi operasi, bisakah Anda melihatnya?"

Ada orang terpisah yang membuat hal-hal baru,

dan saya dipanggil ketika hal baru bertabrakan dengan hal lama.

Pada awalnya, saya tidak begitu menyukainya.

Saya juga ingin melakukan hal-hal baru.

Saya ingin membuat sesuatu yang layak untuk dimasukkan ke dalam slide presentasi.

Menerapkan teknologi baru.

Membuat struktur baru.

Meningkatkan kinerja beberapa kali lipat.

Saya berpikir akan bagus jika nama saya dimasukkan dalam kalimat seperti itu.

Namun, sebagian besar pekerjaan yang saya lakukan sulit dijelaskan.

Analisis dampak sistem yang ada.

Respons masalah operasional.

Integrasi warisan.

Kalibrasi data.

Itu tidak terlihat istimewa.

Hal yang sama terjadi ketika saya pindah perusahaan.

Pewawancara bertanya.

"Peran apa yang terutama Anda lakukan dalam proyek terbaru?"

Saya harus menjelaskan dengan panjang.

Ada sistem pesanan,

ada vendor eksternal,

mobile baru ditambahkan,

ada metode pembayaran yang sudah ada,

dan masalah timbul di antara mereka.

Setelah berbicara sebentar, pewawancara mengangguk.

"Jadi Anda banyak melakukan pekerjaan pemeliharaan."

Mendengar itu membuat mood saya sedikit jatuh.

Pemeliharaan.

Itu bukan kata yang salah.

Tetapi itu terasa seperti kata yang membuat pekerjaan saya sangat kecil.

Untuk sementara, saya menghindari kata itu di resume saya.

Peningkatan sistem.

Stabilisasi layanan.

Pengembangan terintegrasi.

Saya memilih kata-kata yang terlihat sedikit lebih baik.

Tetapi seiring waktu, pendapat saya berubah.

Lebih sulit daripada proyek membangun sistem baru,

pekerjaan menjaga sistem yang sudah berjalan agar tidak berhenti sering lebih sulit.

Saat membuat baru, jika terjadi kesalahan, kami bisa membuat ulang.

Kami tidak bisa melakukan itu dalam operasi.

Saat ini, seseorang memesan, membayar uang, dan menggunakan poin.

Jika diperbaiki dengan salah, itu langsung menjadi insiden.

Bahkan saat memodifikasi satu data, ada banyak hal yang harus diperiksa.

Apakah mengubah nilai ini saja sudah cukup.

Apakah itu tidak terhubung dengan tabel lain.

Apakah batch malam ini tidak akan mengembalikannya ke semula.

Apakah itu tidak mempengaruhi settlement.

Tidak ada yang tahu semuanya dengan tepat.

Orang yang bekerja lama masing-masing mengingat bagian mereka.

"Harus ada alasan mengapa itu diubah seperti itu dulu."

"Apa alasannya?"

"Saya tidak ingat."

Percakapan seperti itu sering terjadi.

Kemudian kami mencari email lama, mencari tiket, dan menggali sumber kode.

Kadang-kadang tidak ada catatan sama sekali.

Dalam hal itu, saya membaca kode dan menebak alasannya.

Mengapa nilai ini diambil lagi di sini?

Mengapa perlu menyimpan dua kali?

Mengapa kondisi ini dimasukkan?

Pada awalnya, bahkan kode yang terlihat aneh dapat dipahami alasannya setelah mengalami satu insiden operasional.

"Ah, itu dimasukkan karena ini."

Momen itu agak menyenangkan.

Saya juga berpikir itu seperti arkeologi.

Pekerjaan melihat jejak yang ditinggalkan seseorang dahulu kala dan menebak situasi saat itu.

Tentu saja, kebanyakan tidak se-romantis itu.

Saya terburu-buru.

Ada telepon dari operasi.

“Pesanan saat ini tidak dapat diterima.”

“Sejak kapan?”

“Sepertinya sudah sepuluh menit.”

Sejak saat itu, pemulihan lebih penting daripada alasannya.

Saya memeriksa log.

Saya memeriksa server.

Saya memverifikasi penerapan terbaru.

Saya memeriksa status DB.

Saya memeriksa status sistem eksternal.

Beberapa tim mengirim pesan secara bersamaan.

Apakah penyebabnya sudah ditemukan?

Apakah ada perkiraan waktu pemulihan?

Pusat layanan pelanggan menerima pertanyaan.

Saya menjawab.

Sedang diperiksa.

Saya menulis kalimat itu sangat sering.

Terkadang saya benar-benar tidak tahu apa-apa.

Tapi saya harus melakukan sesuatu.

Saya menghapusnya satu per satu.

DB normal.

Server normal.

Keterlambatan respons API eksternal.

Tidak ada penerapan terbaru.

Kemudian saya melihat sesuatu yang aneh.

Permintaan tertentu beberapa kali lebih banyak daripada biasanya.

Saya menelusuri penyebabnya.

Salah satu tombol di halaman promosi terhubung dengan buruk.

Setiap kali pengguna mengkliknya, permintaan terjadi beberapa kali.

Ini bukan masalah yang dapat diselesaikan dengan menambahkan server.

Saya menghentikan masalahnya,

mengatur ulang permintaan yang sedang menunggu,

dan memverifikasi pemulihannya.

Setelah sekitar satu jam, tim operasi mengirim pesan.

Konfirmasi normal.

Saya bersandar di kursi.

Orang-orang di sekitar saya bangun dari tempat mereka satu per satu.

Seseorang berkata.

“Anda telah bekerja keras.”

Itu berakhir.

Hari berikutnya semuanya kembali seperti biasa.

Tidak ada presentasi, dan tidak ada hal besar untuk dicatat dalam laporan kinerja.

Layanan itu berhenti dan kemudian berjalan lagi.

Setelah beberapa kali kejadian ini terjadi, saya menyadari sesuatu.

Saya bukan orang yang paling baik dalam membuat hal-hal baru.

Dan anehnya, itu tidak terlalu memalukan seperti sebelumnya.

Ketika ada masalah, saya tahu harus melihat dari mana.

Saya tahu kepada siapa harus bertanya.

Ketika jawabannya tidak terlihat hanya dengan melihat kode, saya tahu harus melihat ke tempat lain.

Ketika orang-orang membawa masalah yang mereka sebut “aneh”, saya bisa mencium di mana letak anehnya.

Itu adalah kemampuan yang sulit dijelaskan.

Tidak ada dalam sertifikasi,

dan agak samar untuk dicantumkan dalam resume seperti nama kerangka kerja.

Tapi itu berguna di lapangan.

Mungkin saya tidak pernah menjadi pengembang yang baik dalam membuat sesuatu.

Sebagai gantinya, saya menjadi pengembang yang dapat melihat apa yang salah dengan hal-hal yang rusak.