tbskit

Topik

DevOps & Sysadmin

Cara kami menangani DevOps & sysadmin: semua sebagai kode, perawatan terjadwal, kontrol akses yang ketat, dan runbook untuk hari buruk.

Situs tidak sehat dengan sendirinya. Topik ini membahas pekerjaan yang menjaganya tetap sehat: otomasi di sekitar setiap perubahan (DevOps) dan perawatan rutin yang tidak glamor pada sistem yang sedang berjalan (sysadmin). Keduanya adalah kebiasaan, dan kebiasaan lebih mudah dipertahankan bila dituliskan dan sebagian diotomatiskan.

Dua sisi dari pekerjaan yang sama

Kedua label ini sering dipakai sebagai satu hal, padahal keduanya menjawab pertanyaan berbeda:

  • DevOps soal perubahan: bagaimana satu commit menjadi deployment, bagaimana lingkungan tetap konsisten, bagaimana rollback terjadi pukul 23.00 tanpa aksi heroik.
  • Sysadmin soal keadaan tetap: apakah situs hidup, apakah backup bisa dipulihkan, apakah sertifikat diperbarui, apakah aksesnya masih pantas, adakah yang diam-diam bergeser.

Proyek yang otomasinya rapi tetapi merawat keadaan tetapnya lalai akan berakhir dengan pipeline indah yang tidak dipantau siapa pun. Proyek yang perawatannya rapi tetapi men-deploy dengan tangan akan berakhir dengan hari rilis yang rapuh. Kami merencanakan keduanya sejak minggu pertama — bahkan untuk proyek kecil, dengan versi kecil dari masing-masingnya.

Semuanya sebagai kode

Kalau sebuah pengaturan hanya ada di sesi browser seseorang, itu adalah risiko. Karena itu kami mendorong konfigurasi masuk ke repositori selama bisa berada di sana:

  • Konfigurasi infrastruktur dan hosting di version control, ditinjau seperti perubahan lain.
  • DNS, redirect, header, dan aturan cache dideklarasikan di proyek, sehingga pertanyaan “bagaimana ini dikonfigurasi?” punya jawaban yang bisa di-diff.
  • Kredensial tidak masuk repositori dan disimpan di secret store platform, dibatasi per lingkungan, dan dirotasi saat seseorang keluar dari proyek.
  • Tidak ada hal penting yang hanya ada di dashboard. Dashboard bagus untuk melihat sekilas, bukan sebagai satu-satunya salinan pengaturan produksi.

Manfaatnya bukan keindahan, melainkan kemampuan memulihkan: situs yang konfigurasinya ada di Git bisa dibangun ulang dari nol, dan pembangunan ulang itu jadi pekerjaan rutin, bukan proyek arkeologi.

Lingkungan yang berperilaku sama

Sebagian besar cerita “di lokal jalan, di produksi rusak” berasal dari lingkungan yang diam-diam berbeda. Aturan kami: jaga perbedaannya sedikit, diketahui, dan terdokumentasi:

  • Proses build sama di mana pun, sehingga build lokal dan build produksi menghasilkan hal yang sama.
  • Lingkungan pratinjau per branch, sehingga meninjau perubahan cukup dengan membuka URL, bukan mengadakan rapat.
  • Data produksi tetap di produksi. Data pelanggan nyata tidak pantas ada di laptop; data uji dibangkitkan atau dianonimkan.
  • Kegagalan terlihat juga saat pengembangan, sehingga pelaporan galat dan logging sudah teruji jauh sebelum hari peluncuran.

Perawatan sesuai jadwal

Menjalankan situs tanpa irama perawatan berarti mengetahui masalah dari orang lain. Kami menjaga kalender yang singkat dan membosankan:

Harian dan mingguan

Pemeriksaan uptime dan galat, peninjauan build yang gagal, sekilas log untuk hal baru yang berulang. Sebagian besar masalah murah di tahap ini dan mahal tiga minggu kemudian.

Bulanan

Tambalan dependensi dan keamanan, uji pemulihan backup pada sampel, peninjauan masa berlaku sertifikat dan domain, serta memastikan notifikasi masih sampai ke manusia.

Triwulanan

Peninjauan akses (siapa masih butuh apa), peninjauan biaya, penyegaran dokumentasi untuk bagian yang berubah, dan menelusuri runbook untuk melihat apakah isinya masih sesuai kenyataan.

Akses dan akuntabilitas

Kontrol akses adalah bagian ops yang paling mudah dilewatkan — sampai ia menjadi penyebab insiden. Yang kami wajibkan:

  • Hak paling minimal, per orang. Login bersama menghapus akuntabilitas dan membuat proses keluar dari proyek jadi tebak-tebakan. Setiap orang punya akun sendiri dengan akses sesuai perannya saja.
  • Two-factor di semua tempat, terutama untuk DNS, hosting, repositori, dan email — empat akun yang bisa menjatuhkan situs atau membocorkannya.
  • Daftar singkat siapa yang boleh men-deploy dan siapa yang boleh mengubah DNS, ditinjau setiap triwulan.
  • Jejak audit. Deploy, perubahan aturan, dan pemberian akses tercatat di tempat yang bisa kami baca nanti, karena “siapa yang mengubah ini?” tidak boleh jadi misteri.
  • Proses keluar berupa daftar periksa, bukan ujian ingatan: kunci dicabut, sesi dimatikan, kredensial dirotasi, akun dihapus.

Saat ada yang rusak

Setiap proyek mendapat runbook, dan setiap insiden mendapat catatan singkat. Runbook menutup sepuluh menit pertama; catatan menutup sepekan berikutnya:

  • Pemeriksaan pertama berurutan: apakah DNS, TLS, deployment, pihak ketiga, atau jaringan pengunjung? Daftar berurutan yang singkat mengalahkan daftar dugaan yang panjang.
  • Siapa yang diberi tahu, dan di mana. Satu tempat untuk menaruh kabar terbaru, supaya tidak ada yang bertanya status ke lima orang berbeda.
  • Cara rollback, ditulis sebelum dibutuhkan, diuji sekali saat cuaca sedang tenang.
  • Tinjauan tanpa mencari kesalahan setelahnya: apa yang terjadi, apa yang kami yakini saat itu, apa yang membuatnya sulit terlihat, dan satu perubahan yang mencegahnya terulang. Keluarannya berupa perbaikan kecil, bukan dokumen yang tidak dibaca siapa pun.
  • Tindak lanjut atas perbaikan itu. Item tindakan tanpa pemilik dan tanggal hanyalah harapan.

Pekerjaan ops yang baik terlihat seperti tidak ada apa-apa yang terjadi. Tandanya membosankan: sedikit perubahan manual, notifikasi yang sampai ke manusia, pemulihan yang benar-benar bekerja, dan tim yang tahu apa yang harus dilakukan pukul 02.00 tanpa membangunkan orang tertentu.

Apa yang kami terbitkan di topik DevOps & Sysadmin

Artikel di topik ini masuk ke detail praktis: menyusun pipeline deploy yang bisa dipercaya, menjaga lingkungan tetap konsisten, merancang backup dan uji pemulihan, merotasi kredensial, memantau situs statis dengan benar, serta keahlian kecil seperti runbook dan catatan insiden.

Bacaan terkait: bagaimana kami menyimpan dan melayani situs, dan standar kode di baliknya.

Menjalankan situs yang sudah melebihi ingatan satu orang? Ceritakan apa yang terus rusak dan kami mulai dari daftar terpendek yang paling banyak mengurangi risiko.

Bekerja Sama

Mari buat website yang mendorong bisnis Anda maju.

Punya proyek di pikiran? Ceritakan apa yang sedang Anda bangun dan kami akan menunjukkan pendekatan kami.

Mulai Proyek