Pelatihan Tertulis DevOps

Bagaimana Cara Melindungi Pipeline Penerapan DevOps Anda?

Setelah tim DevOps dan Anda membangun pipeline yang memungkinkan pengiriman berkelanjutan dengan menerapkan prinsip-prinsip sebelumnya, Anda dapat menerapkan perubahan berisiko rendah ke produksi tanpa persetujuan eksternal. Sebagian besar penerapan tidak lagi perlu melalui proses persetujuan perubahan. Anda mengandalkan desain metodologi pengiriman yang baik, pengujian otomatis, pemantauan otomatis, dan peringatan cerdas dari lingkungan, bukan sekadar mengandalkan otoritas eksternal. Meski demikian, keamanan dan kepatuhan tetap menjadi tanggung jawab penting tim DevOps. Tujuannya memenuhi ketentuan hukum sekaligus menjaga kepentingan klien. Tim tetap bekerja sama dengan pakar keamanan dan kepatuhan di organisasi. Merancang sistem yang aman dan memenuhi hukum yang berlaku harus menjadi kebiasaan sehari-hari.

Jenis Perubahan pada Sistem Produksi

• Perubahan standar: Perubahan berisiko rendah, tidak memerlukan persetujuan, dan cepat diterapkan karena sepenuhnya otomatis dan tercatat. Contohnya pembaruan tabel pencarian basis data, pembaruan konten, perubahan gaya tampilan, serta patch standar untuk sistem operasi, basis data, atau komponen eksternal lain.
• Perubahan normal: Perubahan berisiko tinggi yang memerlukan persetujuan Change Advisory Board (CAB). CAB meminta formulir permintaan perubahan (RFC) untuk menilainya. Prosesnya lama karena anggota CAB sering tidak memiliki cukup pengetahuan untuk melakukan penilaian. Mereka menahan perubahan dan pada akhirnya mengambil keputusan berdasarkan pengalaman, intuisi, dan bias terhadap pihak yang memintanya.
• Perubahan mendesak: Perubahan berisiko tinggi yang memerlukan persetujuan manajemen senior. Contohnya kesalahan kritis di produksi yang berdampak pada klien, perbaikan penerapan bermasalah, patch keamanan, dan pemulihan layanan.

Apa pun jenisnya, Anda dan tim DevOps perlu mendokumentasikan semua perubahan dalam sistem manajemen perubahan dan perencanaan kerja, seperti Remedy dan Jira, agar terlihat oleh semua orang di dalam dan di luar tim.

Gunakan Rekam Jejak Penerapan Otomatis yang Berhasil untuk Mengubah Perubahan Normal Menjadi Standar

Dengan memperbanyak perubahan standar dibandingkan perubahan normal, Anda dapat menghindari proses persetujuan Change Advisory Board (CAB) dan membuat aliran kerja lebih cepat serta pipeline lebih bermutu.

Gunakan riwayat keberhasilan penerapan otomatis untuk mengubah sebanyak mungkin perubahan normal menjadi standar. Tunjukkan kepada CAB rekam jejak dan daftar insiden produksi sebagai bukti bahwa penerapan otomatis tidak menyebabkan insiden atau hanya menimbulkan insiden yang tidak signifikan.

Percepat Penerapan Perubahan Normal

Untuk perubahan yang tetap harus diklasifikasikan normal, otomatisasikan penyusunan formulir permintaan perubahan (RFC). Tautkan semua hasil pengujian otomatis dan manual, insiden yang sudah dan belum diselesaikan, catatan pemantauan, serta log dari lingkungan nonproduksi. Permudah pekerjaan CAB dengan mencantumkan semua informasi yang dibutuhkan pada versi pertama RFC agar persetujuan lebih cepat.

Setelah perubahan disetujui, sediakan penerapan dengan satu klik. Tinjau jenis perubahan normal secara berkala bersama CAB. Identifikasi dan tetapkan kriteria yang dapat meyakinkan mereka untuk mengubahnya menjadi standar, sehingga sebagian besar perubahan dapat diterapkan secara otomatis.

Kurangi Birokrasi dan Ketergantungan pada Pihak Lain dalam Organisasi DevOps

Semakin besar organisasi, semakin banyak peluang bagi birokrasi untuk berkembang. Tanpa disadari, birokrasi dapat tumbuh secara eksponensial dan bertahan selamanya. Jika mengandalkan otoritas dan pengendalian satu tingkat di atas Anda untuk menyetujui pekerjaan, Anda tidak lagi merasa berdaya atau bertanggung jawab atas hasilnya. Akibatnya, pihak yang memberi persetujuan akan berulang kali gagal.

Pada akhirnya, pihak tersebut akan membutuhkan otoritas lain untuk mengandalkan dan mengauditnya. Lingkaran ini berlanjut hingga perusahaan ditata ulang. Sesudahnya, kemungkinan hampir 100% bahwa lingkaran serupa dalam bentuk sedikit berbeda akan menggantikan yang lama.

Ingat bahwa pemisahan tugas serta ketergantungan dan pengendalian dari luar tim dapat memperlambat dan mengurangi mutu pengiriman serta melemahkan keamanan. Sebuah lembaga keuangan besar di Amerika Serikat menjadi korban penipuan ATM akibat pintu belakang yang ditanam pengembang dalam perangkat lunak ATM. Auditor eksternal, pakar keamanan, petugas kepatuhan, dan anggota CAB dari luar tim tidak berhasil menemukan kode penipuan yang diterapkan ke produksi. Kode ini hanya dapat ditemukan oleh tim yang mengembangkannya dengan teknik dasar DevOps seperti pemeriksaan commit dan tinjauan kode.

Untuk mengirimkan hasil dengan cepat dan aman, kurangi ketergantungan pada pihak lain dan pemisahan tugas karena keduanya menghambat tim DevOps mengambil tanggung jawab. Terapkan pengendalian lain dalam tim, seperti pemeriksaan commit, pemrograman berpasangan, tinjauan sejawat, pengujian otomatis, dan pemantauan. Jika hukum mewajibkan pemisahan tugas, pengendalian bawaan tetap membantu auditor dan petugas kepatuhan mengambil keputusan yang lebih baik, cepat, dan berdasarkan informasi.

KESIMPULAN

DevOps menghadirkan dimensi baru yang dinamis bagi kepatuhan dan keamanan informasi. Ketika infrastruktur berbentuk kode, kode membuat sistem muncul dan hilang, serta penerapannya berjalan otomatis, auditor tidak mudah memahami apa yang terjadi. Ini tantangan baru sekaligus peluang untuk membangun mekanisme audit dan kepatuhan yang lebih ringkas dan cerdas serta menyiapkan petugasnya.

Keamanan informasi, kepatuhan, dan kecepatan pipeline adalah tanggung jawab semua orang. Salah satu tujuan utama adalah memberi petugas kepatuhan akses mandiri ke informasi, log, laporan, dan metrik yang membuktikan mutu pengiriman tim DevOps. Hal ini mempermudah proses persetujuan birokratis atau bahkan menghapuskannya sama sekali.