Platform engineer
Platform engineer membangun sebuah produk internal, dan penggunanya adalah engineer organisasi itu sendiri. Keluarannya berupa cara swalayan untuk membuat, merilis, mengamati, dan mengoperasikan service, lengkap dengan jalur-jalur yang ditopang dengan baik yang sudah membawa standar organisasi tanpa perlu dirakit ulang setiap kali. Disiplin ini berhasil atau gagal karena adopsi, dan itu membuatnya sama besar sebagai masalah produk seperti halnya masalah infrastruktur. Berikut cakupan perannya, kapan sebuah organisasi cukup besar untuk membenarkannya, dan cara menilai kandidatnya.
Apa yang dikerjakan seorang platform engineer?
Platform engineer membangun dan menjalankan internal developer platform: permukaan swalayan tempat engineer sebuah organisasi membuat service, men-deploy-nya, memperoleh infrastruktur, mengamati apa yang mereka jalankan, dan mengoperasikannya, tanpa harus memahami atau merakit sendiri komponen di bawahnya. Jalur-jalur yang ditopang dengan baik di platform itu sudah membawa persyaratan organisasi soal keamanan, keandalan, dan biaya sebagai bawaan. Peran ini memperlakukan infrastruktur sebagai sesuatu yang perlu diabstraksikan di balik antarmuka yang dirancang sengaja, dan ia dievaluasi sebagaimana produk mana pun dievaluasi â dari apakah orang yang menjadi tujuannya memilih memakainya.
Gagasan intinya adalah paved road: satu cara yang ditopang dengan baik untuk mengerjakan hal yang lazim, dibuat lebih mudah daripada alternatifnya dan datang dengan persyaratan organisasi sudah terpenuhi. Tim tetap bebas keluar dari jalur itu dan kemudian memikul sendiri apa yang mereka ambil. Itulah beda platform dan mandat â platform membuat jalur yang benar menjadi jalur yang nyaman, sementara mandat membuat jalur yang keliru menjadi terlarang lalu melahirkan penghindaran yang rumit dan biasanya tidak tercatat di mana pun.
Argumen ekonominya adalah soal perhatian. Setiap tim produk yang harus sendirian memikirkan jaringan cluster, pembaruan sertifikat, retensi log, perutean alert, dan izin di penyedia layanan menghabiskan perhatian yang seharusnya bisa masuk ke produknya, dan sampai pada jawaban yang sedikit berbeda dari tim lain mana pun. Sebuah platform layak dibangun begitu keputusan infrastruktur yang sama diambil berulang kali dan tidak konsisten; sebelum itu ia hanyalah abstraksi atas satu kasus, yang biaya pemeliharaannya melebihi duplikasi yang dicegahnya.
Yang paling membedakan disiplin ini dari disiplin di sebelahnya adalah bahwa ia punya pengguna yang boleh menolak. Platform internal yang tidak diadopsi siapa pun bukan keberhasilan setengah jalan â ia adalah beban pemeliharaan yang duduk berdampingan dengan susunan buatan sendiri yang dibangun tim sebagai gantinya. Itu membawa kewajiban khas produk yang biasanya tidak melekat pada pekerjaan infrastruktur: memahami kebutuhan pengguna, dokumentasi, dukungan, pemberian versi, deprecation beserta jalur migrasinya, dan mengukur apakah barangnya benar-benar dipakai.
Kapan tim membutuhkan kapabilitas ini
Platform engineering mudah dimulai terlalu dini, dan ketika itu terjadi ia menghasilkan abstraksi rumit di atas satu kasus pemakaian. Berikut kondisi yang biasanya membuat investasinya mulai terbayar.
Beberapa tim menyelesaikan masalah yang sama dengan cara berbeda
Setiap service punya pendekatan deployment sendiri, konvensi logging sendiri, alerting sendiri, dan tafsir sendiri atas persyaratan keamanannya. Tidak ada yang salah, semuanya sedikit berbeda, dan tidak ada yang bisa berpindah antartim tanpa mempelajari ulang hal-hal dasar. Biaya sesungguhnya bukan pada usaha yang terduplikasi, melainkan pada kenyataan bahwa memperbaiki apa pun berarti mengubahnya di semua tempat.
Memperoleh infrastruktur bergantung pada orang tertentu
Database, queue, environment, atau kredensial baru menuntut meminta kepada seseorang yang sedang sibuk. Delivery kini tergantung pada kalender orang itu, dan organisasinya punya masalah ketersediaan yang dirasakan sebagai masalah kelambatan.
Standar ada sebagai dokumen, bukan sebagai bawaan
Organisasi sudah menuliskan bagaimana service seharusnya menangani secret, retensi, enkripsi, dan alerting, dan kepatuhannya bergantung pada ingatan dan review. Standar yang terdokumentasi diikuti dengan tidak merata; standar yang menyatu ke dalam jalur yang memang sudah ditempuh tim diikuti karena konstruksinya.
Memulai service baru memakan berminggu-minggu pekerjaan yang tak membedakan apa pun
Sebelum satu baris kode produk ditulis, seseorang merakit repositori, pipeline, runtime, secret, monitoring, perutean alert, dan akses. Karena membosankan, tim menghindari membuat service bahkan ketika pemisahan adalah desain yang lebih baik, dan arsitekturnya diam-diam dibentuk oleh biaya penyiapan.
Kelompok infrastruktur berubah menjadi antrean
Permintaan datang lebih cepat daripada diselesaikan, backlog menjadi artefak utamanya, dan kelompok itu diukur dari throughput. Tidak ada yang punya waktu menghilangkan alasan permintaannya ada, jadi antreannya memanjang seefisien apa pun ia dikerjakan. Ini menandakan bentuk pekerjaannya yang perlu berubah, bukan bahwa dibutuhkan lebih banyak tangan.
Jumlah tim di organisasi sudah cukup untuk membuat permukaan bersama terbayar
Platform punya biaya tetap dan manfaatnya menskala mengikuti jumlah tim yang memakainya. Ada ambang â berbeda di setiap tempat, tetapi nyata â yang di bawahnya beberapa template yang terawat dan pustaka modul bersama justru lebih berguna, dan yang di atasnya ketiadaan platform muncul sebagai ketidakkonsistenan di setiap sudut.
Kapabilitas inti
Memperlakukan 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.
Golden 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.
Provisioning 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.
Merancang 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.
Multi-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.
Observability 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.
Policy 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.
Identity 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.
Keandalan 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.
Evolusi 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.
Ekosistem teknologi
Berikut teknologi yang umum dipakai dalam platform engineering. Ini gambaran lanskap disiplinnya secara umum sebagaimana dipraktikkan di pasar, bukan klaim tentang perangkat yang dikuasai engineer mana pun. Platform dirakit alih-alih dibeli, jadi pertanyaan yang lebih berguna adalah bagaimana seseorang memutuskan apa yang dibangun, apa yang diadopsi, dan apa yang dibiarkan saja.
Runtime dan orchestration
- Kubernetes
- Nomad
- ECS
- Cloud Run
- Knative
Developer portal dan antarmuka
- Backstage
- Port
- Cortex
- Humanitec
- CLI internal
Control plane dan provisioning
- Crossplane
- Kubernetes operators
- Kubebuilder
- Modul Terraform
- Pulumi
Konfigurasi dan templating
- Helm
- Kustomize
- CUE
- Jsonnet
- Cookiecutter
Policy dan keamanan workload
- Open Policy Agent
- Kyverno
- Falco
- cert-manager
- External Secrets Operator
- SPIFFE
Telemetri
- OpenTelemetry Collector
- Prometheus Operator
- Grafana
- Tempo
- Pyroscope
Bahasa untuk komponen platform
- Go
- Python
- TypeScript
- Rust
- Shell
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Produk
- Prioritas bisnis
- Roadmap
- Arsitektur
- Prioritas sprint
- Standar engineering
- Kolaborasi teknis sehari-hari
Talent.ID handles
- Hubungan kerja
- Payroll
- Benefit karyawan
- Administrasi talenta
- Hubungan karyawan berkelanjutan
Yang perlu dicari saat menilai kandidat
Platform engineering adalah label yang lebih baru daripada pekerjaan yang digambarkannya, sehingga kini ia menaungi berbagai jenis pekerjaan, sebagian di antaranya pekerjaan infrastruktur biasa yang diberi label baru. Yang membedakan platform engineer sesungguhnya adalah orientasi kepada pengguna internal, dan kemampuan membicarakan adopsi seluwes membicarakan arsitektur.
Orientasi kepada pengguna internal
Tanyakan siapa yang memakai platform terakhir yang mereka garap dan bagaimana mereka mengetahui apa yang dibutuhkan orang-orang itu. Engineer yang mengerjakannya dengan sungguh-sungguh menyebut tim tertentu, keluhan tertentu, dan hal tertentu yang mereka salah menilainya; yang belum menguraikan arsitekturnya dan menganggap kebutuhannya sudah jelas dengan sendirinya.
- Bisa menceritakan fitur yang mereka bangun tetapi diabaikan tim internal, beserta sebabnya
- Pernah duduk bersama tim produk selagi tim itu memakai platformnya
- Membicarakan pengguna platform sebagai orang yang punya pilihan lain, bukan sebagai penerima
- Tahu bagian mana dari platform mereka yang paling banyak dikeluhkan
Pertimbangan dalam berabstraksi
Setiap abstraksi internal pada akhirnya berjumpa dengan kebutuhan yang tidak diantisipasinya. Tanyakan apa yang terjadi ketika itu tiba. Jawabannya mengungkap apakah mereka merancang pintu keluar secara sengaja atau baru menyadari perlunya di tengah perdebatan dengan tim yang sedang dikejar tenggat.
- Menyediakan cara resmi untuk keluar dari abstraksinya alih-alih melarangnya
- Bisa menjelaskan sesuatu yang sengaja mereka pilih untuk tidak disembunyikan
- Pernah menghapus abstraksi yang tidak sepadan dengan biaya pemeliharaannya
Adopsi yang dicapai tanpa mandat
Platform yang dipaksakan lewat keputusan sepihak menumpuk kejengkelan dan akal-akalan; platform yang diadopsi karena memang lebih mudah menumpuk pengguna. Tanyakan bagaimana sebuah tim dibujuk bermigrasi ke sesuatu yang mereka bangun â jawaban yang bagus membuat migrasinya murah alih-alih membuat alternatifnya terlarang.
- Mengukur adopsi dan bisa menyebut angkanya, bukan sekadar bahwa adopsinya tumbuh
- Menurunkan biaya migrasi dengan mengerjakan sebagian pekerjaannya untuk tim itu
- Membedakan platform yang benar-benar diadopsi dari platform yang pemakaiannya diperintahkan
Menjalankan platform sebagai sistem produksi
Platform adalah infrastruktur bagi segala hal lainnya, dan itu mengubah standar yang berlaku baginya. Tanyakan apa yang terjadi pada organisasinya ketika platform mereka tidak tersedia, dan apakah mereka merancangnya agar gagal dalam keadaan terbuka pada bagian yang memang lebih aman begitu.
- Punya sasaran ketersediaan yang eksplisit untuk platformnya sendiri
- Sudah memikirkan kegagalan mana yang tetap harus membiarkan tim melakukan deployment
- Menjalankan on-call platformnya sendiri alih-alih mengalihkan kegagalannya ke tim produk
- Bisa menceritakan satu insiden platform dan perubahan yang dihasilkannya
Guardrail yang tidak berubah menjadi penghalang
Policy otomatis adalah mekanisme yang mengubah standar menjadi bawaan, dan sekaligus cara tercepat membuat sebuah platform dibenci. Tanyakan bagaimana mereka memperkenalkan kontrol yang memblokir sesuatu yang sebelumnya biasa dilakukan tim, dan bagaimana mereka menangani keberatannya.
- Memperkenalkan policy dalam mode laporan saja sebelum menegakkannya
- Menulis pesan penolakan yang menyebutkan apa yang sebaiknya dilakukan sebagai gantinya
- Punya proses pengecualian yang tercatat alih-alih yang bersifat informal
Mengukur developer experience
Tanyakan bagaimana mereka tahu platformnya benar-benar membantu. Kandidat kuat menyebut sesuatu yang teramati â waktu dari repositori kosong sampai service berjalan, seberapa sering tim membuka permintaan dukungan â dan jujur tentang apa yang gagal ditangkap pengukuran itu.
- Memakai ukuran yang terkait dengan pengalaman developer, bukan dengan keluaran platform
- Menggabungkan sinyal kuantitatif dengan berbicara langsung kepada orang yang terdampak
- Bisa menyebut sesuatu yang membaik di atas kertas tetapi tidak dalam praktik
Memensiunkan apa yang mereka bangun sendiri
Antarmuka internal terus menumpuk, dan organisasi yang tidak pernah memensiunkan apa pun akhirnya memelihara setiap versi yang pernah dirilisnya. Tanyakan tentang sesuatu yang pernah mereka tarik, dan simak apakah ada pemberitahuan, tooling migrasi, dan penuntasan â alih-alih sekadar pengumuman dan harapan agar orang patuh.
- Menyediakan migrasi otomatis atau mengerjakan konversinya sendiri
- Memberi pemberitahuan yang sepadan dengan gangguan yang ditimbulkannya
- Memastikan jalur lamanya memang sudah tak terpakai sebelum menghapusnya
Pertanyaan wawancara yang layak diajukan
Pertanyaan yang mengungkap apakah kandidat berpikir dalam kerangka pengguna internal atau hanya dalam kerangka infrastruktur. Semuanya disediakan untuk proses wawancara Anda sendiri â penilaian tentang kecocokan ada di tangan Anda, terhadap persyaratan yang hanya Anda yang bisa menetapkannya.
Gambarkan platform terakhir yang Anda garap. Siapa yang memakainya, dan apa yang mereka lakukan sebelum platform itu ada?
What a strong answer shows
Apakah platformnya dibangun untuk kebutuhan yang teramati atau kebutuhan yang diasumsikan. Separuh kedua pertanyaannya yang paling penting: kandidat yang tidak bisa menggambarkan keadaan sebelumnya kemungkinan besar belum pernah memeriksa apakah platformnya memperbaiki keadaan itu.
Sebuah tim membutuhkan sesuatu yang tidak didukung abstraksi Anda dan mereka sedang dikejar tenggat. Apa yang terjadi?
What a strong answer shows
Cara mereka menangani situasi yang menentukan reputasi sebuah platform. Jawaban kuat menawarkan jalan keluar yang tetap ditopang, memperlakukan celahnya sebagai umpan balik produk, dan menghindari baik pengecualian permanen maupun penolakan mentah.
Bagaimana Anda membuat tim pertama memakai sesuatu yang Anda bangun, dan bagaimana dengan tim kelima?
What a strong answer shows
Metode adopsi, dan kesadaran bahwa keduanya masalah yang berbeda. Tim pertama biasanya kolaborator yang bersedia; tim kelima sudah punya susunan sendiri yang berjalan dan tidak punya alasan khusus untuk berubah.
Platform Anda sedang tidak tersedia. Apa yang masih bisa dilakukan organisasi, dan apa yang berhenti total?
What a strong answer shows
Apakah mereka pernah menalar posisinya sebagai dependensi bagi semuanya. Cari pola kegagalan yang dirancang sengaja, terutama soal apakah tim masih bisa men-deploy perbaikan selagi control plane platformnya sendiri menurun.
Bagaimana Anda menentukan apakah platform bersama memang beralasan di organisasi sebesar ini?
What a strong answer shows
Sikap menahan diri. Kandidat yang percaya setiap organisasi butuh platform akan membangunnya terlalu dini. Jawaban yang matang menimbang jumlah tim, seberapa banyak duplikasi yang ada, dan apakah template serta modul bersama justru lebih berguna untuk sekarang.
Ceritakan sebuah kontrol atau policy yang Anda perkenalkan dan menghentikan tim melakukan sesuatu yang biasa mereka lakukan.
What a strong answer shows
Apakah mereka bisa menegakkan standar tanpa merusak hubungan. Simak adanya masa peringatan, panduan yang jelas di titik penolakan, dan jalur pengecualian yang tercatat alih-alih yang bersifat pribadi.
Apa yang pernah Anda bangun tetapi tidak dipakai siapa pun, dan apa pelajarannya?
What a strong answer shows
Kejujuran dan naluri produk. Semua orang di disiplin ini pernah membangun sesuatu yang diabaikan. Kandidat yang layak dipertimbangkan bisa menyebut apa itu, mengapa mereka salah menilai kebutuhannya, dan apa yang kini mereka periksa sebelum membangun.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- Sebuah organisasi dengan jumlah tim delivery yang terus bertambah mendapati masing-masing merakit caranya sendiri untuk merilis dan mengoperasikan service. Standar ada sebagai panduan tertulis dan diikuti dengan tidak merata, provisioning bergantung pada kelompok kecil yang backlog-nya terus memanjang, dan memulai service baru memakan waktu cukup lama sehingga tim menghindarinya. Permukaan internal bersama sudah disepakati pada tingkat prinsip dan tidak ada kapasitas untuk membangunnya.
- Approach
- Kapasitas tambahan bekerja mengikuti konvensi yang sudah dipegang kelompok platform â desain antarmukanya, proses rilisnya, standar review-nya, dan prioritas yang disepakati dalam perencanaannya. Engineer internal tetap memegang roadmap tentang platform itu akan menjadi apa dan tim mana yang dilayaninya berikutnya, dan jalur-jalur bakunya dibangun berdampingan dengan tim yang akan memakainya.
- What this adds to the team
- Kepemilikan atas arah platform dan hubungannya dengan pengguna internal tetap berada di dalam organisasi. Apa yang diabstraksikan, apa yang tetap terlihat, dan standar mana yang menjadi bawaan diputuskan oleh orang-orang yang akan memeliharanya.
Related disciplines
Frequently asked questions
- 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.
Tell us what your team needs
Describe the gap â the work, the stack, the way your team runs â and we will tell you what we can support. If it is not something we can help with, we will say so.