1 
2Apabila sistem perisian menjadi semakin kompleks  -  mikroservis, Kubernetes, multi-cloud, pipeline CI/CD, timbunan observabiliti  -  pembangun menghabiskan lebih banyak masa pada infrastruktur dan kurang masa membina produk. **Platform Engineering** menyelesaikan masalah ini dengan mencipta platform dalaman yang mengabstrakkan kerumitan dan menyediakan pembangun alat layan diri untuk penghantaran lebih pantas.
3 
4Gartner meramalkan menjelang 2027, **80% organisasi kejuruteraan perisian** akan menubuhkan pasukan platform. Dalam panduan ini, kita akan meneroka apa itu Platform Engineering, mengapa ia penting, dan cara membina Internal Developer Platform dari awal.
5 
6## Apa itu Platform Engineering?
7 
8Platform Engineering ialah disiplin mereka bentuk dan membina rantaian alat dan aliran kerja yang membolehkan keupayaan layan diri untuk organisasi kejuruteraan perisian. Hasilnya ialah **Internal Developer Platform (IDP)**  -  satu lapisan yang berada di antara pembangun dan infrastruktur.
9 
10```mermaid
11graph TD
12    subgraph "Developers"
13        D1[Frontend Team]
14        D2[Backend Team]
15        D3[Data Team]
16    end
17 
18    subgraph "Internal Developer Platform"
19        Portal[Developer Portal]
20        Templates[Service Templates]
21        CICD[CI/CD Pipelines]
22        Infra[Infrastructure Abstraction]
23    end
24 
25    subgraph "Infrastructure"
26        K8s[Kubernetes]
27        Cloud[Cloud Services]
28        DB[Databases]
29        Monitor[Monitoring]
30    end
31 
32    D1 --> Portal
33    D2 --> Portal
34    D3 --> Portal
35    Portal --> Templates
36    Portal --> CICD
37    Portal --> Infra
38    Infra --> K8s
39    Infra --> Cloud
40    Infra --> DB
41    CICD --> Monitor
42```
43 
44### Platform Engineering vs DevOps
45 
46Platform Engineering bukan pengganti DevOps  -  ia adalah evolusi seterusnya. DevOps berkata "anda bina, anda jalankan." Platform Engineering berkata "kami akan menjadikan pembinaan dan penjalanan mudah."
47 
48| Aspek | DevOps | Platform Engineering |
49|-------|--------|---------------------|
50| **Fokus** | Budaya dan amalan | Produk dan layan diri |
51| **Pendekatan** | Setiap pasukan menguruskan infra | Pasukan platform mengabstrakkan infra |
52| **Beban Kognitif** | Tinggi (setiap pasukan mempelajari semuanya) | Rendah (golden path disediakan) |
53| **Output** | Pipeline CI/CD, skrip IaC | Internal Developer Platform |
54| **Pengguna** | Seluruh kejuruteraan | Pasukan platform melayani kejuruteraan |
55 
56## Mengapa Platform Engineering Penting
57 
58### Masalah Beban Kognitif
59 
60Dalam organisasi moden biasa, seorang pembangun perlu memahami:
61 
62- Aliran kerja Git dan strategi pencabangan
63- Konfigurasi pipeline CI/CD
64- Pembinaan kontena dan pengurusan registri
65- Manifest Kubernetes dan Helm Charts
66- Perkhidmatan penyedia awan (AWS/GCP/Azure)
67- Rangkaian, DNS, sijil TLS
68- Persediaan pemantauan, pengelogan, amaran
69- Peruntukan dan migrasi pangkalan data
70- Dasar keselamatan dan pematuhan
71 
72Itu adalah beban kognitif yang sangat besar yang mengalihkan fokus daripada produk sebenar.
73 
74### Golden Path
75 
76Platform Engineering memperkenalkan konsep **golden path**  -  laluan yang berpendirian, disokong dengan baik, dan didokumenkan untuk tugas-tugas biasa. Golden path bukan mandat; pembangun *boleh* menyimpang, tetapi platform menjadikan perkara yang betul sebagai perkara yang mudah.
77 
78```mermaid
79flowchart LR
80    Dev[Developer] -- "Create new service" --> Portal[Portal]
81    Portal -- "Select template" --> Template[Service Template]
82    Template -- "Auto-provision" --> Repo[Git Repository]
83    Template --> Pipeline[CI/CD Pipeline]
84    Template --> Infra[Kubernetes Namespace]
85    Template --> Monitor[Dashboards + Alerts]
86    Repo --> Ready[Ready to Code!]
87```
88 
89**Contoh golden path untuk mencipta mikroservis baharu:**
901. Pembangun memilih "Perkhidmatan Backend Baharu" di portal
912. Memilih bahasa/rangka kerja (Node.js, Go, Python)
923. Platform mencipta secara automatik: repositori Git, pipeline CI/CD, namespace Kubernetes, papan pemuka pemantauan, dan peraturan amaran
934. Pembangun mengklon repositori dan mula mengekod serta-merta
94 
95## Membina Internal Developer Platform
96 
97### Lapisan 1: Developer Portal
98 
99Portal ialah titik masuk tunggal untuk pembangun. Pilihan sumber terbuka paling popular ialah **Backstage** (dicipta oleh Spotify, kini projek CNCF).
100 
101Ciri-ciri utama:
102- **Katalog perkhidmatan**: Setiap perkhidmatan, pemiliknya, dokumentasi, dan kebergantungan
103- **Templat perisian**: Perancah untuk perkhidmatan baharu dengan amalan terbaik terbina
104- **Dokumentasi teknikal**: Dokumentasi sebagai kod, dipapar dan boleh dicari
105- **Ekosistem plugin**: Boleh dikembangkan dengan fungsi tersuai
106 
107```yaml
108# backstage/catalog-info.yaml
109apiVersion: backstage.io/v1alpha1
110kind: Component
111metadata:
112  name: user-service
113  description: Manages user accounts and authentication
114  annotations:
115    github.com/project-slug: myorg/user-service
116    backstage.io/techdocs-ref: dir:.
117spec:
118  type: service
119  lifecycle: production
120  owner: team-auth
121  system: identity-platform
122  dependsOn:
123    - resource:postgresql-main
124  providesApis:
125    - user-api
126```
127 
128### Lapisan 2: Abstraksi Infrastruktur
129 
130Pembangun tidak sepatutnya menulis Terraform atau Kubernetes YAML secara langsung. Platform sepatutnya menyediakan abstraksi.
131 
132**Alat:**
133- **Crossplane**: Peruntukan infrastruktur asli Kubernetes
134- **Terraform dengan modul**: Modul infrastruktur pra-bina dan diuji
135- **Pulumi**: Infrastruktur sebagai kod sebenar (TypeScript, Python, Go)
136 
137```yaml
138# Example: Crossplane composition for a database
139apiVersion: database.example.com/v1
140kind: PostgreSQLInstance
141metadata:
142  name: user-db
143spec:
144  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
145  version: "16"
146  backup: daily
147  team: auth-team
148```
149 
150Daripada mengkonfigurasi parameter RDS, subnet VPC, kumpulan keselamatan, dan dasar sandaran, pembangun hanya menyatakan `size: small` dan `backup: daily`. Platform menguruskan yang selebihnya.
151 
152### Lapisan 3: Penstandardan CI/CD
153 
154Standardkan CI/CD supaya pasukan tidak membina pipeline masing-masing.
155 
156```yaml
157# .github/workflows/platform-ci.yml
158# Teams just include the shared workflow
159name: Build and Deploy
160on:
161  push:
162    branches: [main]
163 
164jobs:
165  pipeline:
166    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
167    with:
168      language: node
169      deploy-target: production
170    secrets: inherit
171```
172 
173**Amalan utama:**
174- Templat CI/CD kongsi yang disertakan oleh pasukan (bukan disalin)
175- Pengimbasan keselamatan automatik (SAST, audit kebergantungan)
176- Strategi penggunaan yang distandardkan (canary, blue/green)
177- Rollback automatik apabila health check gagal
178 
179### Lapisan 4: Observabiliti
180 
181Pemantauan pra-konfigurasi supaya pembangun mendapat papan pemuka dan amaran sedia untuk digunakan.
182 
183- **Metrik**: Prometheus + Grafana dengan papan pemuka standard setiap perkhidmatan
184- **Pengelogan**: Pengelogan berstruktur dengan pengumpulan berpusat (Loki, ELK)
185- **Pengesanan**: Pengesanan teragih dengan OpenTelemetry
186- **Amaran**: Integrasi PagerDuty/Opsgenie dengan lalai yang munasabah
187 
188```mermaid
189graph LR
190    Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]
191    Collector --> Prometheus[Prometheus]
192    Collector --> Loki[Loki]
193    Collector --> Tempo[Tempo]
194    Prometheus --> Grafana[Grafana Dashboards]
195    Loki --> Grafana
196    Tempo --> Grafana
197    Grafana --> PagerDuty[PagerDuty Alerts]
198```
199 
200## Mengukur Kejayaan
201 
202Bagaimana anda tahu platform anda berfungsi? Jejak metrik ini:
203 
204### Metrik DORA
205- **Kekerapan penggunaan**: Berapa kerap kod sampai ke pengeluaran
206- **Masa utama untuk perubahan**: Masa dari commit ke pengeluaran
207- **Kadar kegagalan perubahan**: Peratusan penggunaan yang menyebabkan kegagalan
208- **Masa purata pemulihan**: Masa untuk memulihkan perkhidmatan selepas insiden
209 
210### Metrik Khusus Platform
211- **Masa ke deploy pertama**: Berapa lama dari "perkhidmatan baharu" ke deploy pengeluaran pertama
212- **Kepuasan pembangun (NPS)**: Tinjau pengguna anda dengan kerap
213- **Nisbah layan diri**: % permintaan infrastruktur yang dikendalikan tanpa tiket
214- **Penggunaan golden path**: % perkhidmatan yang mengikuti laluan yang disyorkan
215 
216## Kesilapan Biasa
217 
218### 1. Membina Terlalu Banyak, Terlalu Awal
219Mulakan dengan titik kesakitan terbesar, bukan visi besar. Jika penggunaan menyakitkan, mulakan di situ. Jika peruntukan mengambil masa berminggu-minggu, mulakan di situ.
220 
221### 2. Tidak Melayan Platform sebagai Produk
222Pasukan platform memerlukan pengurus produk, penyelidikan pengguna, dan gelung maklum balas. Pembangun adalah pelanggan anda  -  fahami keperluan mereka.
223 
224### 3. Mewajibkan Berbanding Menarik
225Platform terbaik diterima secara sukarela kerana menjadikan kehidupan pembangun lebih mudah. Jika anda perlu mewajibkan penggunaan, platform anda tidak cukup baik.
226 
227### 4. Mengabaikan Pengalaman Pembangun
228Platform dengan UX yang teruk tidak akan digunakan. Laburkan dalam dokumentasi yang jelas, mesej ralat yang membantu, dan gelung maklum balas yang pantas.
229 
230## Memulakan
231 
232Peta jalan praktikal untuk membina IDP pertama anda:
233 
234```mermaid
235flowchart TD
236    A[Month 1-2: Discovery] --> B[Month 3-4: MVP]
237    B --> C[Month 5-6: Iterate]
238    C --> D[Month 7+: Scale]
239 
240    A --> A1[Interview developers]
241    A --> A2[Map pain points]
242    A --> A3[Choose first golden path]
243 
244    B --> B1[Deploy Backstage]
245    B --> B2[First service template]
246    B --> B3[Standardized CI/CD]
247 
248    C --> C1[Gather feedback]
249    C --> C2[Add infrastructure abstraction]
250    C --> C3[Improve docs and onboarding]
251 
252    D --> D1[More templates and golden paths]
253    D --> D2[Self-service infrastructure]
254    D --> D3[Advanced observability]
255```
256 
257### Platform Minimum Berdaya Maju
258 
2591. **Katalog perkhidmatan** (Backstage)  -  tahu apa yang wujud dan siapa pemiliknya
2602. **Satu templat perkhidmatan**  -  golden path untuk jenis perkhidmatan paling biasa anda
2613. **CI/CD yang distandardkan**  -  pipeline kongsi yang disertakan oleh pasukan
2624. **Dokumentasi asas**  -  cara menggunakan platform, di mana mendapatkan bantuan
263 
264Anda boleh membina MVP ini dalam 2-3 bulan dengan pasukan 2-3 jurutera.
265 
266## Kesimpulan
267 
268Platform Engineering bukan tentang membina platform sempurna dari hari pertama. Ia tentang mengurangkan beban kognitif pembangun secara berperingkat supaya mereka boleh fokus membina produk. Mulakan kecil, ukur impak, dan iterasi berdasarkan maklum balas pembangun.
269 
270Organisasi yang melabur dalam Platform Engineering akan mempunyai kelebihan daya saing yang signifikan: penghantaran lebih pantas, pembangun lebih gembira, dan sistem lebih boleh dipercayai.
271 
272**Sumber:**
273- [Team Topologies](https://teamtopologies.com/)  -  buku yang mempopularkan pasukan platform
274- [Backstage](https://backstage.io/)  -  portal pembangun sumber terbuka Spotify
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  definisi komuniti dan amalan terbaik
276- [platformengineering.org](https://platformengineering.org/)  -  komuniti, acara, dan sumber
277