Platform engineer

Disiplinnya

Kapabilitas inti

• 01Memperlakukan platform sebagai produk

  Mengetahui siapa penggunanya, apa yang mereka lakukan sebelumnya, dan masalah mereka yang mana yang benar-benar dipecahkan platform ini. Ia memikul kewajiban biasa sebuah produk: riset, dokumentasi, dukungan, roadmap yang dipikirkan, dan pengukuran adopsi yang jujur alih-alih pengukuran keluaran.

• 02Golden path dan template service

  Menyediakan jalur yang ditopang dari nol sampai menjadi service yang berjalan, teramati, dan diamankan sepantasnya — scaffolding, pipeline, konfigurasi runtime, telemetri, dan perutean alert datang bersamaan, serta tetap bisa dipelihara setelah tim memodifikasinya.

• 03Provisioning swalayan

  Memungkinkan tim memperoleh database, queue, environment, entri DNS, dan izin lewat permintaan yang dinyatakan dan dipenuhi otomatis, dalam batas yang ditegakkan platform. Keberhasilannya berarti tidak ada yang perlu meminta kepada seseorang, bukan bahwa memintanya jadi lebih cepat.

• 04Merancang abstraksi

  Menentukan apa yang disembunyikan, apa yang ditampakkan, dan di mana pintu keluarnya berada. Sembunyikan terlalu banyak dan sebuah tim terdampar begitu kebutuhannya sedikit tidak lazim; sembunyikan terlalu sedikit dan hasilnya adalah dokumentasi dengan tambahan langkah. Batas inilah pekerjaan intelektual inti disiplin ini.

• 05Multi-tenancy dan isolasi

  Menjalankan workload banyak tim di atas infrastruktur bersama tanpa membiarkan satu tim menurunkan kinerja tim lain: batas sumber daya, batas namespace dan jaringan, kebijakan kuota, serta sikap yang jelas tentang apa yang tetap dijamin platform kepada tenant yang berperilaku buruk.

• 06Observability sebagai bawaan

  Menyertakan instrumentasi bersama paved road sehingga trace, log terstruktur, dan metrik yang berguna sudah ada tanpa setiap tim membangunnya. Inilah beda antara organisasi yang menjadikan monitoring sebagai proyek dan organisasi yang setiap service-nya bisa diselidiki begitu ia berulah.

• 07Policy dan guardrail sebagai kode

  Menuangkan persyaratan menjadi kontrol otomatis — admission policy, aturan provenance image, pembatasan jaringan, deteksi saat runtime — sehingga konfigurasi yang patuh menjadi bawaan dan setiap penyimpangan terlihat. Guardrail yang menolak sesuatu harus menyebutkan apa yang sebaiknya dilakukan sebagai gantinya, kalau tidak tim akan memutarinya.

• 08Identity dan secret untuk workload

  Memberi setiap workload identitas yang bisa diverifikasi dan kredensial berumur pendek yang diterbitkan atas dasar itu, sehingga aplikasi tidak lagi membawa kunci berumur panjang. Distribusi, rotasi, dan pencabutan menjadi sifat platform alih-alih sesuatu yang diimplementasikan berbeda-beda oleh tiap tim.

• 09Keandalan platform itu sendiri

  Platform adalah dependensi bagi semua yang dibangun di atasnya, jadi sasaran ketersediaan dan error budget-nya sendiri lebih penting daripada milik service mana pun. Pola kegagalannya layak mendapat perhatian khusus: platform yang gagal dalam keadaan tertutup bisa menghentikan organisasi melakukan deployment saat insiden, dan justru itulah saat deployment dibutuhkan.

• 10Evolusi antarmuka dan deprecation

  Memberi versi pada apa yang menjadi sandaran tim, dan memensiunkan antarmuka lama dengan jalur migrasi, pemberitahuan yang memadai, dan — bila memungkinkan — konversi otomatis. Deprecation yang ditangani buruk adalah cara tercepat kehilangan kepercayaan yang menjadi tumpuan sebuah platform, dan kepercayaan lebih sulit dibangun ulang daripada mesinnya.

Pertanyaan umum

Pertanyaan yang sering diajukan

Apa bedanya platform engineering dan DevOps?

Keduanya berbeda pada untuk siapa pekerjaannya dan pada apa yang dihasilkannya. DevOps berurusan dengan perpindahan perubahan ke produksi dan sinyal yang kembali sesudahnya, dan biasanya dipraktikkan di dalam sebuah tim delivery untuk kepentingan tim itu. Platform engineering menghasilkan sesuatu yang dikonsumsi banyak tim: produk internal dengan antarmuka swalayan dan jalur-jalur yang ditopang di dalamnya, dipakai tanpa perlu tahu mesin di bawahnya. Yang satu diukur dari seberapa aman dan seberapa sering software sampai ke pengguna; yang lain dari apakah sebuah tim bisa memperoleh yang dibutuhkannya tanpa bantuan. Kerancuannya bisa dimaklumi, karena kelompok platform kerap membangun tooling delivery dan banyak platform engineer datang dari pekerjaan delivery — tetapi platform yang tidak dipakai siapa pun tetap gagal sekalipun setiap pipeline yang dihasilkannya sangat baik.

Apakah platform engineer sekadar infrastructure atau cloud engineer yang berganti nama?

Kadang memang begitu dalam praktiknya, ketika sebuah organisasi mengganti label sebuah tim tanpa mengubah cara kerjanya. Secara hakiki, tidak. Cloud dan infrastructure engineering menghasilkan infrastruktur: topologi account, model identity, postur resiliensi, profil biaya. Platform engineering menghasilkan sesuatu yang dipakai rekan kerja — dengan kewajiban yang menyertai keberadaan pengguna yang bisa pergi ke tempat lain, termasuk dokumentasi, dukungan, pemberian versi, deprecation beserta jalur migrasinya, dan adopsi yang diukur alih-alih diasumsikan. Platform duduk di atas infrastruktur itu dan bergantung pada kesehatannya, dan karena itulah urutannya penting.

Seberapa besar sebuah organisasi harus menjadi sebelum ini beralasan?

Tidak ada ambang universal, tetapi ada satu uji yang andal: hitung berapa kali keputusan infrastruktur yang sama diambil secara terpisah, dan seberapa jauh jawabannya berbeda. Dengan dua atau tiga tim, jawaban jujurnya biasanya adalah template yang terawat, pustaka modul bersama, dan dokumentasi yang jelas. Alasannya menguat seiring bertambahnya jumlah tim dan ketika ketidakkonsistenan menjadi lebih mahal daripada sebuah platform. Membangunnya untuk satu konsumen saja menghasilkan abstraksi yang melayani satu kasus sekaligus merumitkannya.

Apakah pemakaian platform internal sebaiknya diwajibkan?

Menjadikannya pilihan yang paling masuk akal jauh lebih berhasil daripada menjadikannya kewajiban. Mandat mengubah adopsi menjadi kepatuhan, dan itu menyembunyikan umpan balik yang dibutuhkan platform: tim berhenti melaporkan bahwa sesuatu terasa janggal dan mulai diam-diam memutarinya. Beberapa hal memang tidak bisa dinegosiasikan, biasanya kontrol keamanan dan regulasi, dan itu tempatnya di guardrail otomatis yang berlaku baik di dalam maupun di luar paved road. Untuk selebihnya, tim yang memilih alternatif adalah informasi tentang platformnya, bukan tentang timnya.

Apa yang terjadi ketika tim platform berubah menjadi antrean tiket?

Ia berhenti menjadi tim platform dan menjadi loket layanan bersama dengan nama yang berbeda. Pekerjaannya tertata ulang di sekitar menutup permintaan, kelompoknya diukur dari throughput, dan tidak ada yang punya ruang untuk membangun kapabilitas swalayan yang akan membuat permintaan itu tidak diperlukan. Antreannya kemudian tumbuh terlepas dari seefisien apa ia dikerjakan, karena permintaannya justru dihasilkan oleh ketiadaan hal yang tidak sempat dibangun siapa pun akibat antrean itu. Pemulihannya berarti dengan sengaja melindungi kapasitas untuk pekerjaan platform selagi permintaan terus datang, dan itu keputusan tidak nyaman yang hanya bisa diambil pimpinan.

Siapa yang on-call untuk platformnya?

Tim platform, untuk platformnya. Itu salah satu argumen yang paling jelas bagi disiplin ini: ketika sebuah komponen bersama gagal, satu kelompok yang memahaminya yang merespons, alih-alih beberapa tim produk mendiagnosis kesalahan yang sama sendiri-sendiri. Batasnya harus eksplisit — apa yang menjadi tanggung jawab platform, apa yang tetap di tim pemilik sebuah service, dan bagaimana sebuah panggilan dirutekan ketika belum jelas. Keambiguan menghasilkan hasil terburuk, yaitu insiden yang dibuka dengan negosiasi tentang ini masalah siapa.

Bagaimana platform engineer bekerja dengan tim engineering yang sudah ada?

Engineer bergabung ke tim Anda dalam skema penambahan kapasitas tim dan mengikuti cara kerja tim itu: konvensi review-nya, proses rilisnya, arah arsitekturnya, dan prioritas yang ditetapkan dalam siklus perencanaan Anda. Pengarahan pekerjaannya milik Anda, bersama produk, roadmap, dan standar engineering-nya. Talent.ID memegang hubungan kerjanya selama hubungan itu berlanjut, serta mengurus administrasi talenta, payroll, dan benefit karyawan.