Saat Tim Platform Membangun Jalan Tol yang Tidak Dipakai Siapa Pun
Beberapa bulan setelah meluncurkan platform internal baru yang mengilap, sesuatu yang aneh terjadi. Tim platform melihat dashboard mereka bersih. Golden paths sudah didokumentasikan. Pipeline sudah terstandarisasi. Semua tampak benar.
Namun tim aplikasi tidak menggunakannya.
Sebaliknya, mereka menjalankan skrip deployment dari laptop masing-masing. Mereka mendorong Docker image yang tidak pernah melalui pipeline resmi. Mereka menjalankan migrasi database langsung dari terminal. Bukan karena mereka memberontak, tetapi karena platform tidak lagi sesuai dengan cara mereka bekerja.
Ini bukan kegagalan teknologi. Ini adalah kegagalan memperlakukan platform sebagai produk jadi, bukan sebagai layanan yang hidup.
Mengapa Tim Meninggalkan Platform Internal
Tanda pertama masalah biasanya adalah gesekan. Platform dibangun enam bulan lalu dengan versi tertentu dari base image. Sejak saat itu, tim aplikasi mengadopsi cara baru untuk mengelola konfigurasi. Platform tidak mendukungnya. Jadi mereka mencari jalan pintas.
Jalan pintas itu dimulai sebagai celah kecil. Skrip di sini, langkah manual di sana. Seiring waktu, celah-celah ini menjadi jalur tidak resmi. Jalur tersebut tidak dipantau. Tidak aman. Dan tidak terlihat oleh tim platform sampai sesuatu rusak.
Akar masalahnya hampir tidak pernah karena niat buruk. Tim aplikasi diukur berdasarkan pengiriman fitur, bukan kepatuhan terhadap aturan platform. Ketika platform memperlambat mereka, mereka mencari cara yang lebih cepat. Jika tim platform tidak menyadarinya, kesenjangan antara praktik deployment resmi dan aktual akan melebar hingga platform menjadi tidak relevan.
Perlakukan Platform Seperti Produk
Tim platform yang paling efektif berhenti menganggap pekerjaan mereka sebagai infrastruktur. Mereka mulai menganggapnya sebagai produk. Penggunanya bukan pelanggan yang membeli perangkat lunak. Mereka adalah tim teknik lain yang perlu mengirimkan kode setiap hari.
Tim produk tidak meluncurkan fitur lalu pergi begitu saja. Mereka mengamati bagaimana orang menggunakannya. Mereka bertanya apa yang membuat frustrasi. Mereka melakukan iterasi. Tim platform perlu memiliki pola pikir yang sama.
Ini tidak memerlukan proses manajemen produk formal. Bisa dimulai dengan kebiasaan sederhana:
- Lakukan obrolan rutin dengan perwakilan dari tim aplikasi. Tanyakan apa yang membuat mereka lambat minggu ini.
- Adakan survei singkat setiap kuartal. Tanyakan apa yang akan mereka ubah jika bisa.
- Lacak berapa kali orang meminta bantuan terkait platform. Setiap pertanyaan adalah sinyal bahwa ada sesuatu yang tidak jelas atau tidak berfungsi.
Umpan balik tidak akan selalu nyaman. Tim mungkin mengatakan proses build terlalu lambat, dokumentasi sudah usang, atau ada langkah manual yang seharusnya diotomatisasi. Itu bukan kritik. Itu adalah peta jalan.
Jaga Platform Tetap Terbarui
Memperbarui platform tidak hanya tentang menaikkan versi alat. Ini tentang menjaga jalur deployment tetap selaras dengan cara tim benar-benar bekerja.
Jika tim mulai lebih sering menggunakan feature flag, platform harus menyediakan cara yang aman untuk mengelolanya. Jika kerentanan keamanan ditemukan di suatu komponen, platform harus diperbarui sebelum seseorang mengeksploitasinya. Jika versi baru runtime mengubah cara resolusi dependensi, platform harus beradaptasi sebelum tim menemui hambatan.
Pembaruan juga berarti membersihkan. Setiap platform mengumpulkan pipeline lama, skrip tak terpakai, dan lingkungan usang. Jika dibiarkan, ini menjadi jebakan. Anggota tim baru mungkin menemukan pipeline lama yang tampak benar tetapi tidak memiliki pemeriksaan keamanan. Mereka menjalankannya, dan sekarang production memiliki celah yang tidak direncanakan siapa pun.
Membersihkan jalur lama perlu kehati-hatian. Anda tidak bisa menghapus sesuatu yang diandalkan tim tanpa peringatan. Di sinilah kebijakan depresiasi berperan. Ini adalah kesepakatan sederhana: ketika suatu jalur atau fitur akan dihapus, tim platform mengumumkannya lebih awal, menjelaskan alasannya, dan menyediakan panduan migrasi. Tidak ada kejutan. Tidak ada kerusakan mendadak.
Biaya Platform yang Terabaikan
Platform yang tidak dirawat akan ditinggalkan. Tim akan membangun cara deployment mereka sendiri, dan cara-cara itu akan menjadi tidak konsisten dan tidak terpantau. Tim platform mungkin masih ada, tetapi mereka akan memelihara sesuatu yang tidak dipercaya siapa pun.
Platform yang berevolusi bersama penggunanya menjadi tempat di mana tim ingin bekerja. Mereka tidak perlu memikirkan cara deploy. Platform memberi mereka jalur yang aman, cepat, dan sesuai dengan cara mereka benar-benar membangun perangkat lunak.
Ketika itu terjadi, deployment tidak lagi menjadi aktivitas teknis yang dipecahkan sendiri oleh setiap tim. Itu menjadi kemampuan organisasi yang dapat diandalkan oleh seluruh perusahaan.
Daftar Periksa Singkat untuk Tim Platform
Jika Anda bertanggung jawab atas sebuah platform, berikut beberapa hal yang perlu diperiksa secara rutin:
- Kapan terakhir kali Anda berbicara dengan tim aplikasi tentang apa yang membuat mereka frustrasi?
- Apakah ada jalur deployment tidak resmi yang tidak dipantau oleh tim Anda?
- Apakah ada kebijakan depresiasi, atau semuanya hilang begitu saja?
- Kapan terakhir kali Anda memperbarui base image dan dependensi di golden path Anda?
- Apakah tim perlu meminta bantuan lebih dari satu kali untuk masalah yang sama?
Pertanyaan-pertanyaan ini bukan tentang alat. Ini tentang apakah platform Anda masih berguna bagi orang-orang yang bergantung padanya.
Ukuran Sebenarnya dari Sebuah Platform
Platform tidak berhasil karena memiliki dokumentasi yang rapi atau dashboard yang indah. Platform berhasil karena tim memilih untuk menggunakannya, bahkan ketika tidak ada yang mengawasi.
Saat sebuah tim memutuskan untuk mengikuti jalur resmi alih-alih membuat jalan pintas sendiri, saat itulah platform membuktikan nilainya. Dan satu-satunya cara untuk mendapatkan kepercayaan itu adalah dengan terus mendengarkan, terus memperbarui, dan terus menghapus apa yang tidak lagi berfungsi.