Mukadimah Penulis

Assalamualaikum dan salam sejahtera. Terima kasih kerana memuat turun Ebook DevOps Dengan AI.

Dua tahun lepas, kalau saya nak bina satu modul Terraform untuk VPC, saya buka dokumentasi, buka contoh projek lama, dan tulis satu persatu. Ambil masa dua jam. Hari ini, dengan AI, saya tulis kemahuan saya dalam lima ayat, semak output dalam sepuluh minit, dan modul itu siap dengan variable, tag, dan dokumentasi sekali. Dua jam jadi dua puluh minit.

Tapi ini bukan cerita “AI ganti kerja saya”. Ini cerita “AI buang kerja yang tak sepatutnya saya buat”.

Saya mula guna AI untuk kerja infra secara serius pada 2025. Bukan sebab hype, tetapi sebab saya penat. Penat tulis YAML yang sama, penat semak plan Terraform yang panjang, penat baca log ribuan baris untuk cari satu punca masalah. Dari situ saya cari, cuba, dan buang cara yang tak jadi, sampai tinggal aliran kerja yang saya pakai setiap hari sehingga sekarang.

Apa yang anda akan dapat:

Cara fikir yang betul tentang AI dalam kerja DevOps, dan bila JANGAN percaya dia
Setup aliran kerja AI yang selamat, termasuk guardrail supaya AI tak sentuh production
Aliran kerja praktikal untuk Terraform, Ansible, Docker, dan CI/CD
10 prompt siap pakai yang boleh anda salin terus
Checklist keselamatan sebelum terima kod daripada AI

Siapa yang sesuai baca ebook ini: engineer yang sudah tahu asas DevOps dan nak kerja lebih cepat; pelajar atau career switcher yang baru masuk bidang infra; freelancer atau solo engineer yang urus banyak sistem seorang diri.

Siapa yang mungkin tak sesuai: yang belum tahu asas Linux, Git, dan rangkaian. AI tak ganti asas. Kalau anda tak faham rangkaian, AI akan beri jawapan yang nampak betul tetapi salah, dan anda tak akan perasan.

Jadi semua aliran kerja, cara fikir dan pengalaman saya dedahkan di dalam ebook ini. Selepas anda baca dan faham, cubalah satu peraturan pertama itu dahulu: AI cadang, anda sahkan. Nanti anda akan nampak sendiri beza dia.

Tanpa tindakan, ianya hanyalah sekadar ilmu yang tak mampu menghasilkan apa-apa. Bertindaklah walaupun ianya belum sempurna.

Syafiyullah Yahya Web: www.notainfra.com

Syarat dan Amaran

DevOps Dengan AI

Hak Cipta Terpelihara

Hakcipta terpelihara. Tidak dibenarkan mengeluar ulang mana-mana bahagian artikel, ilustrasi dan isi kandungan Ebook ini dalam apa jua bentuk dan dengan apa cara sekalipun, sama ada secara elektronik, fotokopi, rakaman atau cara lain sebelum mendapat izin bertulis daripada Syafiyullah Yahya.

Tanggungjawab hakcipta tidak ada kena mengena dengan maklumat yang terkandung di dalam Ebook ini. Pihak penerbit dan penulis tidak bertanggungjawab ke atas sebarang kesilapan ataupun maklumat yang tidak dimasukkan walaupun langkah berjaga-jaga sudah diambil. Pihak penerbit dan penulis juga tidak bertanggungjawab ke atas sebarang maklumat yang disalahgunakan.

Penafian

Penerbitan ini mengandungi pandangan serta pengalaman penulis dan juga sumber dari yang boleh dipercayai. Ia bertujuan membantu dan menyediakan maklumat berkenaan perkara yang dibincangkan.

Penulis dan penerbit tidak bertanggungjawab ke atas mana-mana kerugian, kehilangan atau risiko yang ditanggung oleh perseorangan atau sebagainya, yang timbul akibat daripada penggunaan mana-mana kandungan Ebook ini sama ada secara langsung ataupun tidak langsung.

Semua contoh kod, konfigurasi, arahan, dan prompt dalam Ebook ini disediakan “seadanya” tanpa jaminan dalam apa jua bentuk. Output AI boleh mengandungi kesilapan fakta, rujukan yang tidak wujud, atau amalan yang tidak selamat. Pembaca bertanggungjawab sepenuhnya untuk menguji dan mengesahkan semua output sebelum menggunakannya dalam persekitaran production.

Jangan sekali-kali membenarkan AI menjalankan arahan pada sistem production tanpa semakan manusia dan mekanisme rollback. Jangan masukkan credential, kunci API, atau data pelanggan ke dalam prompt.

Nama produk, jenama, dan tanda dagangan yang disebut dalam Ebook ini adalah hak milik pemilik masing-masing dan digunakan untuk tujuan pengenalan sahaja.

Terma dan Syarat Penggunaan

Penulis memberi lesen untuk kegunaan individu pembaca sahaja. TIADA Lesen “Private Label Rights” atau “Master Resell Rights” dibekalkan untuk Ebook ini.

Anda TIDAK dibenarkan sama sekali menyalin, mengubah, atau menggunakan kandungan ini untuk membuat kelas, seminar, atau kursus berbayar, dan juga tidak dibenarkan menjualnya kembali sama ada dalam bentuk Ebook, video atau bercetak.

Anda DIBENARKAN berkongsi Ebook ini secara percuma kepada sesiapa yang boleh manfaat daripadanya, asalkan kandungannya tidak diubah dan tiada bayaran dikenakan.

Versi: 1.0 (Edisi Lead Magnet) Tarikh Terbit: 2026 Diterbitkan oleh: Syafiyullah Yahya · www.notainfra.com

Bab 1: Kenapa DevOps + AI

Bab ini bukan tentang tool. Ia tentang cara fikir. Kalau cara fikir betul, tool apa pun boleh pakai.

Ramai orang mula dengan soalan “AI apa yang paling power?” Itu soalan yang salah. Soalan yang betul ialah “bahagian mana kerja saya yang berulang?” Jawapan kepada soalan itu yang menentukan sama ada AI jimatkan masa anda atau tambah kerja semakan.

Apa yang anda akan belajar:

Apa sebenarnya yang berubah dalam kerja DevOps sejak AI jadi mampu
Di mana AI menang, dan di mana dia gagal secara senyap
Formula masa yang saya guna untuk nilai sama ada satu tugas sesuai untuk AI
Satu peraturan yang saya tak pernah langgar

1.1 Tiga Gelombang, dan Kita Sekarang di Gelombang Ketiga

Cara AI membantu kerja teknikal berubah tiga kali.

Gelombang 1: Autocomplete. AI teka baris seterusnya. Berguna untuk tulis kod berulang, tetapi dia tak faham konteks keseluruhan projek anda.

Gelombang 2: Chat. Anda tampal kod, tanya soalan, dia jawab. Lebih baik, tetapi anda masih perlu salin tampal, dan AI masih buta tentang fail sebenar dalam repo anda.

Gelombang 3: Agent. AI boleh baca fail dalam repo anda, jalankan arahan, lihat output, dan buat pembetulan sendiri. Inilah yang mengubah kerja infra secara nyata. Anda boleh kata “semak kenapa pipeline ni gagal”, dan dia boleh buka fail workflow, jalankan test secara lokal, dan cadang pembetulan.

Yang penting: gelombang ketiga bukan bermakna anda hilang kawalan. Ia bermakna anda kena lebih berhati-hati tentang had kuasa yang anda beri.

1.2 Di Mana AI Menang Besar

Selepas setahun guna setiap hari, ini senarai kerja yang saya serahkan hampir sepenuhnya kepada AI:

Boilerplate Infrastructure as Code. Modul Terraform, variable, output, tag piawai. Kerja yang formatnya sama setiap kali.
Terjemahan antara tool. Tukar skrip bash lama jadi playbook Ansible. Tukar perintah manual jadi Makefile. Ini kerja hafalan sintaks, bukan kerja fikir.
Semakan pertama kod. Cari credential yang tertinggal, port yang terbuka, imej yang guna tag latest, IAM policy yang terlalu luas.
Dokumentasi dan runbook. AI sangat baik untuk ubah kod jadi penerangan. Dan dokumentasi yang ditulis lepas kod siap biasanya lebih tepat daripada yang ditulis sebelum kerja bermula.
Triage log. Beri satu fail log, minta dia kelaskan ralat mengikut punca dan kekerapan. Ini jimat masa yang banyak.
Penulisan ujian. Anda terangkan kelakuan yang betul, dia tulis ujian. Anda semak sama ada ujian itu benar-benar menguji perkara yang betul.

Kalau kerja itu ada corak yang berulang dan hasilnya boleh disemak, ia sesuai untuk AI.

Kitaran DevOps dengan AI di setiap peringkat

Rajah 1: Setiap peringkat kerja DevOps boleh dipercepatkan dengan AI, tetapi keputusan seni bina, keselamatan, dan kos kekal pada manusia.

1.3 Di Mana AI Gagal Secara Senyap

Ini bahagian yang lebih penting, sebab kegagalan AI jarang berbunyi kuat. Dia gagal dengan yakin.

Resource atau atribut yang tak wujud. AI akan tulis aws_instance.foo.bar yang nampak masuk akal tetapi tak ada dalam versi provider yang anda guna.
Versi yang sudah lapuk. Modul atau sintaks yang betul pada 2023 boleh jadi salah hari ini.
Kod yang jalan tetapi tak selamat. Dia akan guna 0.0.0.0/0 pada security group sebab itu yang paling senang bagi dia.
Andaian bahawa semuanya idempotent. Ansible task yang guna shell: boleh jalan sepuluh kali dan hasilnya berbeza setiap kali.
Diagnosis tanpa konteks. AI tak nampak metrics, trace, atau tahu apa yang berubah semalam. Dia hanya nampak apa yang anda beri.

Peraturan saya ringkas: AI cadang, engineer sahkan. Setiap baris kod infra yang masuk ke production mesti melalui otak manusia yang faham akibatnya. AI mempercepatkan kerja menulis. Ia tidak memindahkan tanggungjawab.

1.4 Formula 80/20 untuk Tugas Infra

Setiap kali saya dapat tugas baru, saya tanya satu soalan: berapa bahagian kerja ini yang berulang?

Kalau 80 peratus berulang, saya guna AI untuk draf pertama, kemudian guna masa yang dijimatkan untuk semak dengan teliti. Kalau 20 peratus yang berulang, saya tulis sendiri dan guna AI hanya sebagai pemeriksa.

Contohnya, bina modul VPC untuk projek bootcamp. Strukturnya berulang: VPC, subnet, internet gateway, route table, security group. Yang tidak berulang cuma keputusan reka bentuk: berapa subnet, siapa boleh masuk, di mana NAT gateway diletakkan. Jadi AI buat 80 peratus, saya fokus pada 20 peratus yang menentukan sama ada sistem itu selamat dan murah.

1.5 Satu Peraturan yang Tak Pernah Saya Langgar

AI tidak pernah diberi kebenaran menjalankan arahan yang mengubah production tanpa semakan manusia dan plan terlebih dahulu.

Maksudnya dalam praktik:

AI boleh baca apa sahaja dalam repo.
AI boleh jalankan arahan read-only dan ujian lokal.
AI mesti berhenti pada terraform plan, ansible --check, atau kubectl --dry-run.
Manusia yang tekan butang apply.

Kalau anda baru mula, jadikan peraturan ini kebiasaan dari hari pertama. Ia murah untuk dipatuhi, dan sangat mahal bila dilanggar.

1.6 Apa Anda Perlukan Sebelum Mula

Anda tidak perlukan tool mahal. Anda perlukan tiga benda:

Repo yang kemas. AI baca struktur, bukan fikiran anda. Folder yang dinamakan jelas membuat output dia jauh lebih baik.
Sekurang-kurangnya satu ujian atau plan. Tanpa jaringan keselamatan, anda tak akan tahu bila AI salah.
Persekitaran sandbox. Akaun cloud berasingan atau homelab. Jangan belajar AI di atas sistem production yang menyara hidup anda.

Bab seterusnya akan tunjukkan cara susun kerja ini supaya ia selamat dan berulang.

Bab 2: Setup Aliran Kerja AI

Ramai orang guna AI dan rasa ia tidak membantu. Sembilan puluh peratus sebabnya bukan AI, tetapi setup. Mereka beri AI konteks yang lemah, harapkan keajaiban, dan dapat output generik.

Bab ini tunjuk cara susun aliran kerja supaya AI betul-betul berguna untuk kerja infra anda.

Apa yang anda akan belajar:

Pilih antara model cloud dan model lokal, dan bila guna yang mana
Cara beri AI konteks tentang repo dan infrastruktur anda
Lima guardrail yang saya pasang sebelum benarkan AI sentuh apa-apa
Tiga anti-corak yang buat kerja anda bertambah susah

2.1 Pilih Tool: Cloud atau Lokal

Ada dua pilihan besar. Kedua-duanya ada tempat.

Model cloud (Claude Code, Codex, Copilot, Cursor dan seumpamanya) sesuai untuk kerja harian: kepantasan tinggi, faham codebase besar, dan boleh baca banyak fail serentak. Ini pilihan lalai saya untuk kerja repo biasa.

Model lokal (Ollama dengan model seperti Qwen Coder atau Codestral) sesuai bila data tidak boleh keluar dari mesin anda. Contohnya kod pelanggan yang ada NDA, kredensial sensitif, atau konfigurasi rangkaian dalaman. Ia lebih perlahan dan kurang bijak, tetapi ia kekal dalam LAN anda.

Peraturan mudah:

Kerja biasa, kod awam, homelab: cloud.
Kod client, data peribadi, dokumen dalaman: lokal.
Ragu-ragu: guna lokal. Kalau ia tak cukup kuat, pecahkan tugas kepada bahagian yang lebih kecil.

2.2 Beri AI Konteks: Fail Arahan dalam Repo

Ini satu perubahan kecil yang memberi kesan paling besar. Letakkan satu fail arahan di akar repo. Claude Code membaca CLAUDE.md, Codex dan tool lain membaca AGENTS.md. Isinya lebih kurang begini:

# AGENTS.md

## Struktur repo
- terraform/ : infra AWS, satu folder satu environment
- ansible/   : konfigurasi server
- app/       : aplikasi yang di-deploy

## Cara uji
- IaC: terraform fmt -check, terraform validate, tflint
- Ansible: ansible-lint, run dengan --check --diff
- App: npm test

## Peraturan
- JANGAN jalankan terraform apply, ansible-playbook tanpa --check,
  atau sebarang arahan yang mengubah production.
- Jangan letak credential dalam kod atau dalam prompt.
- Semua resource mesti ada tag: Project, Environment, Owner.
- Guna versi Terraform dan provider yang dipin dalam versions.tf.
- Jawab dalam Bahasa Melayu.

## Konvensyen
- Nama resource: <projek>-<komponen>-<env>
- Commit: Conventional Commits (feat:, fix:, chore:)

Fail ini mengambil masa lima belas minit untuk ditulis, dan anda akan dapat hasilnya setiap hari selepas itu. Ia juga berfungsi sebagai dokumentasi untuk manusia baru dalam pasukan.

2.3 Susun Repo Supaya AI Faham

AI tak tahu apa yang tidak ada dalam repo. Susun begini:

infra/
  terraform/
    modules/
      vpc/
      compute/
    environments/
      dev/
      prod/
  ansible/
    inventories/
      dev.ini
      prod.ini
    roles/
  .github/workflows/

Kunci pada pemisahan modules dan environments. Anda mahu AI boleh ubah modul tanpa sentuh konfigurasi production secara tak sengaja, dan sebaliknya.

2.4 Lima Guardrail

Ini yang saya pasang sebelum benarkan AI bantu kerja infra.

Lima lapisan guardrail

Rajah 2: Lima lapisan guardrail. Setiap satu murah dipasang, dan sangat mahal bila dilanggar.

1. Tiada credential dalam prompt. Kalau saya perlu AI faham bentuk konfigurasi, saya tukar nilai sebenar dengan placeholder. Sekali credential masuk ke log perbualan, anda kena rotate.

2. Akses read-only secara lalai. Akaun cloud yang AI guna untuk terokai sumber sepatutnya hanya boleh baca. Hak tulis diberi secara sedar untuk tugasan tertentu sahaja.

3. Plan gate sebelum apply. Tiada pengecualian. AI berhenti pada plan, manusia semak, kemudian baru apply. Plan yang panjang pun boleh disemak cepat dengan minta AI sendiri meringkaskan perubahan, tetapi keputusan tetap pada anda.

4. Kerja melalui branch dan pull request. Walaupun anda solo engineer. Ia memberi anda diff yang boleh dibaca, sejarah yang boleh dirujuk, dan jalan keluar yang mudah kalau sesuatu jadi salah.

5. Ujian sebelum percaya. Kalau AI kata sesuatu berfungsi, jalankan sendiri. Saya dah terlalu banyak kali jumpa kod yang “sepatutnya jalan” tetapi gagal pada kali pertama dijalankan.

2.5 Cara Ajar AI Tentang Infra Anda

Teknik yang paling berkesan: beri contoh sebenar, bukan penerangan abstrak.

Tunjuk satu modul Terraform yang anda dah tulis dan suka. Minta AI ikut corak yang sama.
Beri output plan atau log ralat yang penuh, bukan ringkasan. AI lebih baik mencari punca bila dia nampak data mentah.
Beritahu apa yang sudah dicuba dan gagal. Ini mengelak dia cadang benda yang sama berulang kali.
Satu tugas, satu sesi. Sesi panjang bercampur topik menghasilkan jawapan yang bercampur juga.

2.6 Tiga Anti-Corak

Anti-corak 1: “Baiki semua.” Arahan kabur menghasilkan perubahan besar yang tak boleh disemak. Sebaliknya: “Tambahkan validation untuk variable cidr_block supaya hanya terima /16 ke /24.”

Anti-corak 2: Benarkan AI jalankan arahan berbahaya. Jangan pernah bagi kebenaran lalai untuk apply, destroy, rm, atau ubah firewall production. Setiap satu perlu kelulusan manusia.

Anti-corak 3: Terima kod yang anda tak faham. Kalau anda tak boleh jelaskan kepada rakan sekerja kenapa kod itu ditulis begitu, jangan merge. Ini bukan soal ego, tetapi soal anda akan jadi orang yang dipanggil bila ia rosak pada jam 3 pagi.

Setup anda sekarang sudah cukup. Bab seterusnya masuk ke kerja sebenar: Terraform.

Bab 3: Terraform dengan AI

Terraform adalah tempat AI memberi pulangan paling besar, sebab kerja ini penuh dengan corak berulang tetapi sintaksnya ketat. Satu koma salah, plan gagal. AI sangat baik untuk bahagian sintaks, tetapi teruk untuk bahagian reka bentuk. Jadi bahagikan kerja mengikut itu.

Apa yang anda akan belajar:

Aliran kerja lima langkah untuk bina modul dengan AI
Perkara yang mesti disemak setiap kali AI tulis kod Terraform
Cara pasang plan gate dalam pull request
Dua kes sebenar dari projek saya

3.1 Aliran Kerja Lima Langkah

Langkah 1: Tulis kemahuan dalam ayat biasa. Bukan minta kod dulu. Terangkan apa yang anda mahu wujud.

Langkah 2: Minta rangka, bukan penyelesaian penuh. Minta struktur fail, variable, dan output sebelum minta isi.

Langkah 3: Semak rujukan terhadap versi sebenar. Ini langkah yang paling ramai terlepas. AI boleh reka atribut. Semak dengan dokumen provider atau terraform providers schema -json.

Langkah 4: Minta validation dan ujian. Variable dengan validation block, dan terraform validate dalam pipeline.

Langkah 5: Plan dan semak. Jalankan terraform plan. Baca. Barulah apply.

Contoh prompt untuk Langkah 2:

Saya mahu modul Terraform untuk VPC di AWS dengan keperluan ini:
- CIDR 10.0.0.0/24
- Dua subnet: public 10.0.0.0/25 dan private 10.0.0.128/25
- Public subnet guna internet gateway, private subnet guna NAT gateway
- Tag piawai: Project, Environment, Owner
- Terraform 1.7+, provider AWS 5.x

Beri saya:
1. Struktur fail modul (main.tf, variables.tf, outputs.tf, versions.tf)
2. Senarai variable dengan jenis dan default
3. Penjelasan ringkas setiap resource dan kenapa ia perlu

Jangan tulis kod penuh dulu.

Selepas anda setuju dengan struktur, barulah minta kod. Pendekatan ini mengelak AI menulis tiga ratus baris yang anda perlu buang.

3.2 Semak Apa Selepas AI Tulis

Senarai semak saya setiap kali:

Versi provider dan Terraform dipin dalam versions.tf, bukan latest.
Atribut yang wujud. Kalau ragu, rujuk dokumen provider untuk versi yang anda pin.
Tiada hard-code. AMI id, nombor akaun, dan nama bucket mesti jadi variable atau data source.
Security group. Cari 0.0.0.0/0 pada port selain 80 dan 443. Setiap satu perlu justifikasi.
Tag. Guna default_tags pada provider supaya konsisten, bukan tag berulang pada setiap resource.
Backend. Remote state dengan locking, bukan state lokal.
Sumber kos. NAT gateway, instance besar, dan EBS yang tidak dipakai adalah tiga penyumbang bil paling biasa.

3.3 Plan Gate dalam Pull Request

Ini yang membuat AI selamat. Setiap perubahan infra mesti melalui plan yang boleh dibaca oleh manusia sebelum apply.

Aliran plan gate

Rajah 3: AI berhenti pada plan. Manusia yang semak diff dan tekan apply.

name: Terraform Plan

on:
  pull_request:
    paths: ['infra/terraform/**']

permissions:
  contents: read
  pull-requests: write

jobs:
  plan:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: infra/terraform/environments/dev
    steps:
      - uses: actions/checkout@v4

      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.7.5

      - name: Auth ke AWS (OIDC, tiada kunci kekal)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-terraform-plan
          aws-region: ap-southeast-5

      - run: terraform fmt -check
      - run: terraform init -input=false
      - run: terraform validate
      - run: terraform plan -input=false -no-color -out=tfplan

Perhatikan tiga benda: guna OIDC supaya tiada access key disimpan dalam GitHub, permissions dikecilkan, dan job ini hanya buat plan. Apply adalah workflow berasingan yang memerlukan kelulusan manusia.

3.4 Kes Satu: Modul VPC dalam Dua Puluh Minit

Ini dari projek akhir bootcamp DevOps saya. Peserta perlu bina VPC dengan subnet awam dan persendirian, satu web server di subnet awam, dan server monitoring di subnet persendirian.

Cara saya buat dengan AI:

Saya tulis kemahuan dalam bentuk bullet, seperti prompt di atas.
AI cadang struktur fail. Saya betulkan dua perkara: NAT gateway mahal untuk projek pelajar, jadi saya guna NAT instance sahaja, dan saya minta setiap resource ada tag.
AI tulis kod. Saya semak security group dan dapati satu rule membenarkan SSH dari mana-mana. Saya tukar kepada CIDR saya.
terraform plan dijalankan. Saya minta AI ringkaskan plan itu dalam lima baris, kemudian saya semak sendiri bahagian yang melibatkan rangkaian.
Apply.

Jumlah masa: kira-kira dua puluh minit berbanding dua hingga tiga jam kalau tulis dari kosong. Yang penting, masa yang dijimatkan itu saya guna untuk semak keselamatan, bukan untuk minum kopi.

3.5 Kes Dua: Import Sumber yang Sudah Ada

Sumber yang dicipta secara manual adalah masalah biasa. Cara AI membantu:

Saya ada security group sg-0abc123 yang dicipta manual di AWS
(region ap-southeast-5). Saya mahu ia diurus oleh Terraform tanpa
memusnahkannya dan tanpa downtime.

Tunjukkan:
1. Blok resource yang sepadan dengan keadaan semasa
2. Arahan terraform import
3. Cara sahkan plan jadi kosong selepas import

Kunci di sini ayat “tanpa memusnahkannya”. Tanpa itu, AI mungkin cadang tukar nama resource yang akan menyebabkan ia dimusnahkan dan dicipta semula. Semak plan, pastikan tiada -/+ destroy and then create.

3.6 Kos: Guna AI, Tapi Sahkan dengan Data

AI berguna untuk cadang right-sizing dan cari sumber terbiar, tetapi jangan percaya angka. Minta dia semak dari data sebenar:

Ini output aws ce get-cost-and-usage untuk 30 hari lepas.
Kenal pasti tiga perkhidmatan dengan kos tertinggi dan cadang
satu tindakan konkrit untuk setiap satu. Untuk setiap cadangan,
nyatakan risiko dan cara mengesahkannya.

Kemudian sahkan dalam Cost Explorer. AI yang tak nampak tagihan sebenar akan memberi cadangan generik seperti “guna reserved instance”, yang belum tentu sesuai untuk beban kerja anda.

Bab seterusnya: konfigurasi server dan container.

Bab 4: Ansible dan Docker dengan AI

Kalau Terraform membina infrastruktur, Ansible dan Docker menguruskan apa yang berjalan di atasnya. Kedua-duanya penuh dengan sintaks yang mengingat bukan memahami, dan itulah sebabnya AI sangat berguna di sini.

Apa yang anda akan belajar:

Cara minta AI tulis playbook yang idempotent
Empat kesilapan Ansible yang AI selalu buat
Cara kecilkan imej Docker dengan bantuan AI
Rutin semakan sebelum imej masuk ke registry

4.1 Ansible: Minta Idempotency Secara Terang

Masalah nombor satu dengan playbook yang ditulis AI ialah ia guna shell: atau command: untuk semua benda. Cara itu jalan, tetapi ia bukan idempotent dan ia menyukarkan debugging.

Sentiasa sebut perkataan idempotent dalam prompt, dan nyatakan modul yang anda mahu.

Tulis satu Ansible role untuk setup Nginx di Ubuntu 24.04.

Syarat:
- Guna modul ansible.builtin sahaja, FQCN penuh
- Idempotent: run kedua tidak boleh ubah apa-apa
- Guna handler untuk restart nginx, bukan task restart di hujung
- Jangan guna shell: atau command: kalau ada modul yang sesuai
- Tambah ansible-lint fqcn dan no-changed-when

Beri saya tasks/main.yml, handlers/main.yml, dan defaults/main.yml.
Terangkan setiap task dalam satu baris.

Empat kesilapan yang selalu muncul, dan cara betulkan:

shell: untuk kerja yang ada modul. Tukar kepada ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.template.
Tiada changed_when. Task yang selalu melaporkan perubahan mengaburkan perubahan sebenar.
Restart service di tengah task. Guna handler supaya restart berlaku sekali sahaja di hujung.
Root tanpa had. Guna become: true hanya pada task yang perlu, bukan pada keseluruhan play.

4.2 Uji Sebelum Sentuh Server Sebenar

Ansible ada dua jaringan keselamatan. Guna kedua-duanya.

ansible-lint roles/nginx
ansible-playbook -i inventories/dev.ini site.yml --check --diff

--check menjalankan playbook dalam mod simulasi. --diff menunjukkan apa yang akan berubah. Kalau AI kata playbook itu selamat, buktikan dengan dua arahan ini sebelum ia menyentuh server production.

Untuk tahap seterusnya, minta AI tulis ujian dengan Molecule. Ia lebih banyak kerja pada awalnya, tetapi ia menjadikan role anda boleh dipercayai semula tanpa perlu uji manual setiap kali.

4.3 Rahsia: Jangan Sesekali dalam Kod

AI suka letak nilai dalam vars. Jangan benarkan.

Ubah playbook ini supaya tiada satu pun credential tertulis dalam
fail. Guna ansible.builtin.lookup dengan environment variable yang
diisi dari secret manager (contoh: Infisical atau Vault).
Tunjukkan contoh cara mengisi variable itu semasa run.

Kemudian sahkan sendiri: grep -ri "password\|token\|secret" roles/ dan pastikan tiada nilai sebenar. Ini satu arahan yang patut jadi kebiasaan sebelum setiap commit.

4.4 Docker: Kecilkan Imej, Kurangkan Risiko

Imej yang besar bukan sekadar lambat. Ia mengandungi lebih banyak pakej, dan lebih banyak pakej bermakna lebih banyak kelemahan yang boleh dieksploitasi.

Prompt yang saya guna:

Ini Dockerfile aplikasi Node.js. Kecilkan imej dan kurangkan risiko:

- Guna multi-stage build
- Base image: node:22-alpine atau distroless, pilih satu dan jelaskan
- Jangan lari sebagai root
- Pin versi base image
- .dockerignore yang betul
- HEALTHCHECK

Terangkan anggaran saiz imej akhir dan risiko setiap perubahan.

Biasanya saiz turun dari lebih satu gigabait kepada bawah dua ratus megabait. Tetapi semak sendiri dengan:

docker build -t app:test .
docker history app:test
docker run --rm -p 3000:3000 app:test

Perhatikan docker history. Kadang kala rahsia terlekat dalam layer lama walaupun ia dipadam dalam layer berikutnya. Kalau ada rahsia dalam sejarah imej, imej itu perlu dibina semula dari awal, bukan ditampal.

4.5 Semakan CVE dan Tag

Dua kebiasaan mudah yang menyelamatkan banyak masalah:

Scan sebelum push. Jalankan trivy image app:test atau docker scout cves app:test dalam pipeline. Gagalkan build kalau ada kelemahan kritikal.
Jangan guna tag latest. Pin kepada versi atau digest. latest bermakna deploy anda boleh berubah tanpa perubahan kod.

Minta AI semak keseluruhan repo untuk kedua-dua perkara ini:

Cari semua rujukan imej Docker dalam repo ini.
Senaraikan yang menggunakan tag latest atau tiada tag,
dan cadangkan versi yang sesuai untuk dipin.

4.6 Sambungan ke Homelab

Kalau anda ada homelab, ini tempat terbaik untuk berlatih. Bina satu role Ansible yang setup Docker dan Nginx pada dua mesin, jalankan dengan --check dahulu, kemudian jalankan sebenar. Ulang kali sampai anda yakin.

Kemahiran yang sama inilah yang digunakan untuk urus seratus server. Bezanya cuma skala, dan skala hanya masuk akal selepas asas ini kukuh.

Bab seterusnya: mengalirkan semua ini melalui CI/CD.

Bab 5: CI/CD dengan AI

CI/CD adalah tempat kesilapan paling mahal, sebab pipeline yang salah boleh memusnahkan production tanpa amaran. AI sangat membantu untuk menulis pipeline, tetapi ia juga sangat pandai menghasilkan pipeline yang nampak betul tetapi longgar dari segi keselamatan.

Apa yang anda akan belajar:

Cara minta AI tulis workflow GitHub Actions yang selamat
Perkara yang mesti disemak dalam setiap workflow
Cara nyahpepijat pipeline yang gagal tanpa membuang masa
Aliran kerja PR ke production yang saya guna

5.1 Prompt Asas untuk Pipeline

Tulis GitHub Actions workflow untuk projek Node.js ini.

Keperluan:
- Trigger: pull_request dan push ke main
- Job: lint, test, build
- Node 22, guna cache npm
- permissions: contents: read sahaja
- concurrency supaya push berturut-turut tidak bertindih
- Pin setiap action kepada versi major (contoh: @v4)
- Jangan letak sebarang secret dalam fail workflow

Terangkan setiap blok dalam satu baris.

Empat perkara dalam prompt itu bukan hiasan:

permissions mengecilkan kuasa token. Tanpa ini, workflow anda boleh menulis ke repo dan mengubah release.
concurrency mengelak dua deploy berjalan serentak dan saling menimpa.
Pin versi action. Action pihak ketiga tanpa pin adalah risiko supply chain.
Tiada secret dalam fail. Rujuk secrets.* sahaja.

5.2 OIDC: Buang Kunci Kekal dari GitHub

Amalan lama menyimpan AWS_ACCESS_KEY_ID dalam GitHub Secrets. Amalan yang lebih baik ialah OIDC, di mana GitHub mendapat token sementara daripada AWS, dan tiada kunci kekal disimpan di mana-mana.

Minta AI bantu, tetapi berhati-hati: bahagian yang paling mudah salah ialah trust policy. Pastikan ia terhad kepada repo dan branch yang betul.

Saya mahu GitHub Actions deploy ke AWS tanpa access key kekal.
Beri saya:
1. IAM role trust policy untuk OIDC, terhad kepada repo
   syafi-dev/infratify dan branch main sahaja
2. IAM policy minimum untuk deploy ke S3 dan invalidate CloudFront
3. Blok aws-actions/configure-aws-credentials yang sepadan
Jelaskan setiap condition dan kenapa ia perlu.

Semak sub condition. Kalau ia benarkan semua branch atau semua repo, sesiapa yang boleh buka PR boleh mengakses akaun AWS anda.

5.3 Nyahpepijat Pipeline yang Gagal

Ini penggunaan AI yang paling jimat masa. Tetapi ada cara betul untuk minta.

Cara salah: tampal satu baris ralat dan tanya kenapa.

Cara betul:

Pipeline gagal pada step "Run tests".

Ini fail workflow penuh: <tampal>
Ini log penuh dari awal step yang gagal: <tampal>
Ini perubahan terakhir dalam commit ini: <git diff>

Sebelum cadang penyelesaian:
1. Senaraikan tiga punca paling mungkin mengikut kebarangkalian
2. Untuk setiap punca, beri bukti dari log yang menyokong atau menafikan
3. Barulah cadang satu pembetulan yang paling kecil

Arahan “sebelum cadang penyelesaian” mengubah kualiti jawapan secara ketara. AI berhenti meneka dan mula membaca.

5.4 PR Review oleh AI, Kelulusan oleh Manusia

AI boleh jadi penyemak pertama yang tidak pernah jemu. Pasang aliran ini:

Setiap PR, minta AI semak diff untuk: credential yang tertinggal, perubahan yang longgar pada firewall atau IAM, tag imej latest, dan perubahan yang tak sepadan dengan peraturan dalam AGENTS.md.
Hasil semakan AI masuk sebagai komen, bukan sebagai kelulusan.
Manusia yang tekan merge.

Satu peraturan tambahan yang penting: AI tidak dibenarkan meluluskan PR yang ia sendiri tulis. Kalau tidak, anda sedang menguji kerja sendiri.

5.5 Aliran Kerja PR ke Production

Ini susunan yang saya guna. Ia perlahan pada pandangan orang yang suka deploy terus, tetapi ia membenarkan saya tidur lena.

PR dibuka. Lint, test, dan semakan AI berjalan.
Plan dijalankan untuk perubahan infra dan komen dalam PR.
Manusia semak dan merge ke main.
Deploy ke dev secara automatik.
Production memerlukan kelulusan. Guna GitHub Environments dengan required reviewers. Deploy tidak bermula sehingga seseorang tekan setuju.
Smoke test selepas deploy. Sekurang-kurangnya satu arahan yang sahkan endpoint utama hidup.
Rollback disediakan. Kalau deploy anda tiada jalan balik, anda tiada CI/CD. Anda ada risiko berjadual.

5.6 Commit, Changelog, dan Notifikasi

Tiga tugas kecil yang boleh diserahkan sepenuhnya kepada AI tanpa banyak risiko:

Mesej commit. Minta AI tukar diff jadi mesej Conventional Commits. Hasilnya lebih konsisten daripada yang ditulis manusia yang penat.
Changelog. Hasilkan dari senarai commit antara dua tag. Semak sekali sebelum publish.
Notifikasi deploy. Minta AI tulis langkah yang hantar mesej ke Telegram atau Slack selepas deploy berjaya atau gagal. Nyatakan versi dan commit hash, bukan hanya “deploy selesai”.

Pipeline anda sekarang punya penjaga. Bab seterusnya memberi anda alat untuk bekerja lebih pantas: sepuluh prompt yang boleh anda salin terus.

Bonus 1: 10 Prompt Siap Pakai

Salin terus. Ganti bahagian dalam kurungan dengan butiran projek anda. Setiap prompt ditulis supaya AI memberi jawapan yang boleh disemak, bukan jawapan yang perlu anda percaya bulat-bulat.

1. Modul Terraform Baru

Bina modul Terraform untuk [komponen] di AWS.

Keperluan:
- [senaraikan keperluan]
- Tag piawai: Project, Environment, Owner
- Pin versi Terraform dan provider

Mula dengan struktur fail dan senarai variable sahaja.
Jangan tulis kod penuh sehingga saya setuju dengan reka bentuk.

2. Semak Plan Terraform

Ini output terraform plan. Ringkaskan:
1. Resource yang akan dicipta, diubah, dan dimusnahkan
2. Perubahan yang berisiko downtime atau kehilangan data
3. Resource yang akan dicipta semula (destroy and recreate)

Jangan cadang perubahan. Hanya laporkan apa yang plan katakan.

3. Role Ansible Idempotent

Tulis Ansible role untuk [tugasan] pada [OS].

Syarat: guna modul ansible.builtin FQCN, idempotent, handler untuk
restart service, tiada shell atau command kalau ada modul yang sesuai.
Sertakan cara uji dengan ansible-lint dan --check --diff.

4. Dockerfile Slim

Ini Dockerfile saya. Kecilkan imej dan kurangkan risiko:
multi-stage build, bukan root, pin versi base image, .dockerignore,
HEALTHCHECK. Beri anggaran saiz akhir dan risiko setiap perubahan.

5. Pipeline GitHub Actions

Tulis GitHub Actions workflow untuk [jenis projek].
Trigger [pull_request/push]. Job: lint, test, build.
permissions contents: read sahaja. Guna cache. Guna concurrency.
Pin setiap action kepada versi major. Tiada secret dalam fail.

6. Nyahpepijat Pipeline

Pipeline gagal pada step [nama].
Fail workflow: [tampal]
Log penuh: [tampal]
Diff commit terakhir: [tampal]

Senaraikan tiga punca paling mungkin dahulu dengan bukti dari log.
Selepas itu baru cadang satu pembetulan paling kecil.

7. Triage Log

Ini log [perkhidmatan] untuk [tempoh].
Kelaskan ralat mengikut punca, bukan mengikut masa.
Untuk setiap punca: kekerapan, kesan kepada pengguna, dan
satu langkah pengesahan seterusnya.
Abaikan amaran yang tidak berulang.

8. Runbook

Tulis runbook untuk [insiden] berdasarkan konfigurasi dalam repo ini.

Format:
- Gejala yang pengguna nampak
- Cara sahkan dalam 2 minit pertama
- Tiga punca paling biasa dan cara mengenal pastinya
- Langkah pemulihan, termasuk cara rollback
- Apa yang perlu didokumen selepas insiden selesai

9. Semak Kos Cloud

Ini data kos 30 hari. Kenal pasti tiga penyumbang teratas
dan cadang satu tindakan untuk setiap satu.
Untuk setiap cadangan: anggaran penjimatan, risiko, dan cara sahkan.
Jangan cadang apa-apa tanpa data yang menyokong.

10. Semakan Keselamatan Kod AI

Semak fail ini untuk masalah keselamatan sahaja:
credential tertulis, input tanpa validasi, kebenaran terlalu luas,
imej tanpa pin, dan ralat yang didedahkan kepada pengguna.
Untuk setiap penemuan: fail, baris, kesan, dan cadangan pembetulan.
Jangan komen gaya kod.

Cara Guna Prompt Ini dengan Betul

Tiga peringatan ringkas:

Prompt adalah titik mula, bukan penyelesaian. Selepas AI jawab, tanya “apa yang mungkin salah dengan cadangan ini?” Dia selalunya tahu, tetapi dia tak akan sebut kalau anda tak tanya.
Satu tugas, satu sesi. Jangan campur lima tugas dalam satu perbualan panjang.
Simpan yang berjaya. Jadikan folder prompt peribadi anda. Prompt yang bagus adalah aset.

Penutup

Anda sudah sampai ke penghujung bahagian percuma ini. Kalau anda baca dengan teliti dan cuba satu atau dua prompt dalam bab bonus, anda sudah punya sesuatu yang tidak dimiliki oleh ramai engineer: aliran kerja yang menggabungkan kepantasan AI dengan kawalan manusia.

Tiga benda untuk dibawa keluar dari ebook ini.

Pertama: AI mempercepatkan kerja menulis, bukan kerja berfikir. Keputusan tentang seni bina, keselamatan, dan kos masih milik anda. Itulah bahagian yang majikan bayar.

Kedua: asas tak boleh dilangkau. Saya selalu beritahu peserta bootcamp saya, kalau anda tak faham rangkaian, AI akan beri jawapan yang nampak betul tetapi salah, dan anda tak akan perasan. Asas adalah kemampuan anda untuk mengesan kesilapan. AI tanpa asas cuma menghasilkan keyakinan tanpa kemahiran.

Ketiga: semak, selalu semak. Setiap baris kod infra yang masuk ke production mesti melalui mata manusia yang faham akibatnya. Ini bukan kerana AI tidak berguna, tetapi kerana tanggungjawab itu tidak pernah berpindah.

Apa Seterusnya

Bahagian percuma ini meliputi bab yang paling cepat memberi hasil. Versi penuh merangkumi perkara yang membezakan engineer biasa dengan engineer yang dipertanggungjawabkan:

Monitoring dan observability dengan AI: triage log, kurangkan alert noise, jana runbook insiden
AI untuk keselamatan: pengurusan rahsia, semakan IAM, supply chain
AI untuk kos cloud: analisis bil dan right-sizing berdasarkan data sebenar
AI di homelab: jalankan model sendiri, akses AI dari dalam LAN, auto-dokumentasi
Kerjaya DevOps dengan AI: apa majikan cari 2027 dan bagaimana menunjukkannya dalam portfolio
Projek akhir berpandu: bina satu sistem lengkap yang boleh dimasukkan ke dalam portfolio

Kalau anda mahu versi penuh, muat naik dan langgan di www.notainfra.com.

Satu Permintaan

Kalau ebook ini berguna, balas dan beritahu saya bahagian mana yang paling membantu, dan bahagian mana yang mengelirukan. Saya baca setiap maklum balas, dan ia menentukan apa yang saya tulis seterusnya.

Kalau anda rasa ia berguna untuk rakan sepasukan, hantar kepada mereka. Ilmu ini menjadi lebih berguna apabila lebih ramai orang dalam pasukan anda memahaminya.

Akhir sekali, terima kasih kerana meluangkan masa. Bidang ini berubah setiap tahun, dan orang yang terus belajar adalah orang yang terus relevan.

Selamat membina.

Syafiyullah Yahya www.notainfra.com

Mukadimah Penulis

Syarat dan Amaran

Hak Cipta Terpelihara

Penafian

Terma dan Syarat Penggunaan

Bab 1: Kenapa DevOps + AI

1.1 Tiga Gelombang, dan Kita Sekarang di Gelombang Ketiga

1.2 Di Mana AI Menang Besar

1.3 Di Mana AI Gagal Secara Senyap

1.4 Formula 80/20 untuk Tugas Infra

1.5 Satu Peraturan yang Tak Pernah Saya Langgar

1.6 Apa Anda Perlukan Sebelum Mula

Bab 2: Setup Aliran Kerja AI

2.1 Pilih Tool: Cloud atau Lokal

2.2 Beri AI Konteks: Fail Arahan dalam Repo

2.3 Susun Repo Supaya AI Faham

2.4 Lima Guardrail

2.5 Cara Ajar AI Tentang Infra Anda

2.6 Tiga Anti-Corak

Bab 3: Terraform dengan AI

3.1 Aliran Kerja Lima Langkah

3.2 Semak Apa Selepas AI Tulis

3.3 Plan Gate dalam Pull Request

3.4 Kes Satu: Modul VPC dalam Dua Puluh Minit

3.5 Kes Dua: Import Sumber yang Sudah Ada

3.6 Kos: Guna AI, Tapi Sahkan dengan Data

Bab 4: Ansible dan Docker dengan AI

4.1 Ansible: Minta Idempotency Secara Terang

4.2 Uji Sebelum Sentuh Server Sebenar

4.3 Rahsia: Jangan Sesekali dalam Kod

4.4 Docker: Kecilkan Imej, Kurangkan Risiko

4.5 Semakan CVE dan Tag

4.6 Sambungan ke Homelab

Bab 5: CI/CD dengan AI

5.1 Prompt Asas untuk Pipeline

5.2 OIDC: Buang Kunci Kekal dari GitHub

5.3 Nyahpepijat Pipeline yang Gagal

5.4 PR Review oleh AI, Kelulusan oleh Manusia

5.5 Aliran Kerja PR ke Production

5.6 Commit, Changelog, dan Notifikasi

Bonus 1: 10 Prompt Siap Pakai

1. Modul Terraform Baru

2. Semak Plan Terraform

3. Role Ansible Idempotent

4. Dockerfile Slim

5. Pipeline GitHub Actions

6. Nyahpepijat Pipeline

7. Triage Log

8. Runbook

9. Semak Kos Cloud

10. Semakan Keselamatan Kod AI

Cara Guna Prompt Ini dengan Betul

Bonus 2: Checklist Keselamatan Sebelum Merge

Tiga Soalan Sebelum Percaya Output AI

Infrastructure as Code

Ansible dan Konfigurasi

Docker dan Container

CI/CD

Rahsia dan Kebersihan Repo

Amalan Harian

Penutup

Apa Seterusnya

Satu Permintaan