Daftar periksa DevOps

  • Artikel
  • 13 menit untuk membaca

DevOps adalah integrasi pengembangan, jaminan kualitas, dan operasi TI ke dalam budaya terpadu dan serangkaian proses untuk mengirimkan perangkat lunak. Gunakan daftar periksa ini sebagai titik awal untuk menilai budaya dan proses DevOps Anda.

Budaya

Pastikan keselarasan bisnis di seluruh organisasi dan tim. Konflik atas sumber daya, tujuan, sasaran, dan prioritas dalam suatu organisasi dapat menjadi risiko bagi keberhasilan operasi. Pastikan bahwa tim bisnis, pengembangan, dan operasi sudah selaras.

Pastikan bahwa tim memahami siklus hidup perangkat lunak. Tim Anda perlu memahami siklus hidup aplikasi secara keseluruhan, dan bahwa aplikasi berada dalam siklus hidup tersebut. Ini membantu semua anggota tim mengetahui apa yang harus mereka lakukan sekarang, dan apa yang harus mereka rencanakan dan persiapkan di masa depan.

Kurangi waktu siklus. Bertujuan untuk meminimalkan waktu yang diperlukan untuk beranjak dari ide ke perangkat lunak yang telah dikembangkan dan dapat digunakan. Batasi ukuran dan cakupan rilis individu untuk menjaga agar beban pengujian tetap rendah. Otomatiskan proses pembangunan, pengujian, konfigurasi, dan penyebaran jika memungkinkan. Hapus semua hambatan untuk komunikasi antar-pengembang, dan antara pengembang dan operasi.

Tinjau dan tingkatkan proses. Proses dan prosedur Anda, baik otomatis maupun manual, tidak pernah final. Siapkan peninjauan rutin alur kerja, prosedur, dan dokumentasi saat ini, dengan tujuan peningkatan berkelanjutan.

Lakukan perencanaan proaktif. Buat rencana untuk menghadapi kegagalan secara proaktif. Siapkan proses untuk mengidentifikasi masalah dengan cepat saat masalah tersebut terjadi, sampaikan hal tersebut ke anggota tim yang tepat untuk perbaikan, dan konfirmasikan resolusinya.

Belajarlah dari kegagalan. Kegagalan tidak dapat dihindari, tetapi penting untuk belajar dari kegagalan agar tidak terulang kembali. Jika terjadi kegagalan operasional, lakukan triase masalah, dokumentasikan penyebab dan solusinya, serta bagikan pelajaran yang didapat. Jika memungkinkan, perbarui proses pembangunan untuk mendeteksi jenis kegagalan tersebut secara otomatis di masa mendatang.

Optimalkan kecepatan dan kumpulkan data. Setiap peningkatan yang direncanakan adalah hipotesis. Bekerja dalam tahapan sekecil mungkin. Perlakukan ide-ide baru sebagai eksperimen. Instrumentasikan eksperimen sehingga Anda dapat mengumpulkan data produksi untuk menilai keefektifannya. Bersiaplah untuk cepat gagal jika hipotesisnya salah.

Berikan waktu untuk belajar. Kegagalan dan keberhasilan sama-sama memberikan kesempatan untuk belajar. Sebelum Anda beralih ke proyek baru, sediakan waktu yang cukup untuk mengumpulkan pelajaran penting, dan pastikan pelajaran tersebut diserap oleh tim Anda. Selain itu,beri tim waktu untuk membangun keterampilan, bereksperimen, dan belajar tentang alat dan teknik baru.

Dokumentasikan operasi. Dokumentasikan semua alat, proses, dan tugas otomatis dengan tingkat kualitas yang sama dengan kode produk Anda. Dokumentasikan desain dan arsitektur terkini dari sistem apa pun yang Anda dukung, bersama dengan proses pemulihan dan prosedur pemeliharaan lainnya. Fokuslah pada langkah-langkah yang memang Anda lakukan, bukan proses yang optimal secara teoritis. Tinjau dan perbarui dokumentasi secara teratur. Untuk kode, pastikan bahwa komentar yang bermakna disertakan, terutama di API publik. Gunakan alat untuk menghasilkan dokumentasi kode secara otomatis bila memungkinkan.

Bagikan pengetahuan. Dokumentasi hanya berguna jika orang tahu bahwa dokumentasi tersebut ada dan jika mereka dapat menemukannya. Pastikan dokumentasi dibuat teratur dan mudah ditemukan. Jadilah kreatif: gunakan pelatihan informal (presentasi informal), video, atau buletin untuk berbagi pengetahuan.

Pengembangan

Beri pengembang lingkungan seperti produksi. Jika lingkungan pengembangan dan pengujian tidak cocok dengan lingkungan produksi, sulit untuk menguji dan mendiagnosis masalah. Oleh karena itu, jaga agar lingkungan pengembangan dan pengujian sedekat mungkin dengan lingkungan produksi. Pastikan data uji konsisten dengan data yang digunakan dalam produksi, meskipun itu adalah data sampel dan bukan data produksi nyata (untuk alasan privasi atau kepatuhan). Rencanakan untuk membuat dan menganonimkan data uji sampel.

Pastikan bahwa semua anggota tim yang berwenang dapat memprovisikan infrastruktur dan menyebarkan aplikasi. Penyiapan sumber daya seperti produksi dan penyebaran aplikasi tidak boleh melibatkan tugas manual yang rumit atau pengetahuan teknis sistem yang terperinci. Siapa pun yang memiliki izin yang tepat harus dapat membuat atau menyebarkan sumber daya seperti produksi tanpa harus pergi ke tim operasi.

Rekomendasi ini tidak menyiratkan bahwa siapa saja dapat mendorong pembaruan langsung ke penyebaran produksi. Rekomendasi ini berhubungan dengan mengurangi friksi bagi pengembangan dan tim QA dalam menciptakan lingkungan seperti produksi.

Instrumentasikan aplikasi untuk insight. Untuk memahami kesehatan aplikasi Anda, Anda perlu mengetahui bagaimana performanya dan apakah aplikasi mengalami kesalahan atau masalah. Selalu sertakan instrumentasi sebagai persyaratan desain, dan bangun instrumentasi ke dalam aplikasi sejak awal. Instrumentasi harus menyertakan pengelogan peristiwa untuk analisis akar masalah, tetapi juga telemetri dan metrik untuk memantau kesehatan dan penggunaan aplikasi.

Lacak hutang teknis Anda. Dalam banyak proyek, jadwal rilis lebih diprioritaskan daripada kualitas kode sampai tingkat tertentu. Selalu lakukan pelacakan saat hal ini terjadi. Dokumentasikan semua pintasan atau implementasi suboptimal lainnya, dan jadwalkan waktu untuk meninjau kembali masalah ini.

Pertimbangkan untuk mendorong pembaruan langsung ke produksi. Untuk mengurangi waktu siklus rilis keseluruhan, pertimbangkan untuk mendorong penerapan kode yang telah diuji dengan benar langsung ke produksi. Gunakan pengalih fitur untuk mengontrol fitur mana yang diaktifkan. Ini memungkinkan Anda berpindah dari pengembangan ke rilis secara cepat, dengan menggunakan pengalih untuk mengaktifkan atau menonaktifkan fitur. Pengalih juga berguna saat melakukan pengujian seperti rilis Kenari, yang memungkinkan fitur tertentu disebarkan ke subset lingkungan produksi.

Pengujian

Otomatiskan pengujian. Menguji perangkat lunak secara manual itu membosankan dan rentan terhadap kesalahan. Otomatiskan tugas pengujian umum dan integrasikan pengujian ke dalam proses pembangunan Anda. Pengujian otomatis memastikan cakupan pengujian dan reproduktifitas yang konsisten. Pengujian UI yang terintegrasi juga harus dilakukan oleh alat otomatis. Azure menawarkan sumber daya pengembangan dan pengujian yang dapat membantu Anda mengonfigurasi dan mengeksekusi pengujian. Untuk informasi selengkapnya, lihat Pengembangan dan pengujian.

Uji untuk kegagalan. Jika suatu sistem tidak dapat tersambung ke layanan, bagaimana responsnya? Bisakah sistem pulih ketika layanan kembali tersedia? Jadikan pengujian injeksi kesalahan sebagai bagian standar dalam tinjauan terhadap lingkungan pengujian dan penyusunan tahap. Saat proses dan praktik pengujian Anda sudah matang, pertimbangkan untuk menjalankan pengujian ini dalam produksi.

Uji dalam produksi. Proses rilis tidak berakhir dengan penyebaran ke produksi. Lakukan pengujian untuk memastikan bahwa kode yang disebarkan berfungsi seperti yang diharapkan. Untuk penyebaran yang jarang diperbarui, jadwalkan pengujian produksi sebagai bagian rutin dari pemeliharaan.

Otomatiskan pengujian performa untuk mengidentifikasi masalah performa lebih awal. Dampak dari masalah performa yang serius bisa separah bug dalam kode. Meskipun pengujian fungsional otomatis dapat mencegah bug aplikasi, pengujian tersebut mungkin tidak mendeteksi masalah performa. Tentukan sasaran performa yang dapat diterima untuk metrik seperti latensi, waktu muat, dan penggunaan sumber daya. Sertakan pengujian performa otomatis dalam alur rilis Anda, untuk memastikan aplikasi memenuhi tujuan tersebut.

Lakukan pengujian kapasitas. Aplikasi mungkin bekerja dengan baik di bawah kondisi pengujian, lalu bermasalah dalam produksi karena keterbatasan skala atau sumber daya. Selalu tentukan kapasitas maksimum yang diharapkan dan batas penggunaan. Uji untuk memastikan aplikasi dapat menangani batas tersebut, tetapi juga uji apa yang terjadi ketika batas tersebut terlampaui. Pengujian kapasitas harus dilakukan secara berkala.

Setelah rilis awal, Anda harus menjalankan pengujian performa dan kapasitas setiap kali pembaruan dilakukan pada kode produksi. Gunakan data historis untuk menyempurnakan pengujian dan untuk menentukan jenis pengujian apa yang perlu dilakukan.

Lakukan pengujian penetrasi keamanan otomatis. Memastikan aplikasi Anda aman sama pentingnya dengan menguji fungsionalitas lainnya. Jadikan pengujian penetrasi otomatis sebagai bagian standar dari proses pembangunan dan penyebaran. Jadwalkan pengujian keamanan reguler dan pemindaian kerentanan pada aplikasi yang disebarkan, yang memantau port terbuka, titik akhir, dan serangan. Pengujian otomatis tidak menghilangkan kebutuhan akan peninjauan keamanan mendalam secara berkala.

Lakukan pengujian kelangsungan bisnis otomatis. Kembangkan pengujian untuk kelangsungan bisnis skala besar, termasuk pemulihan cadangan dan failover. Siapkan proses otomatis untuk melakukan pengujian ini secara rutin.

Rilis

Mengotomatiskan penyebaran. Mengotomatiskan penyebaran aplikasi untuk pengujian, staging, dan lingkungan produksi. Automation memungkinkan penyebaran yang lebih cepat dan andal, serta memastikan penyebaran yang konsisten ke lingkungan apa pun yang didukung. Ini menghilangkan risiko kesalahan manusia yang disebabkan oleh penyebaran manual. Ini juga memudahkan penjadwalan rilis untuk waktu yang tepat, guna meminimalkan efek dari potensi waktu henti. Miliki sistem untuk mendeteksi masalah apa pun selama peluncuran, dan miliki cara otomatis untuk menggulung ke depan perbaikan atau menggulung balik perubahan.

Gunakan integrasi berkelanjutan. Integrasi berkelanjutan (CI) adalah praktik menggabungkan semua kode pengembang ke dalam basis kode pusat pada jadwal reguler, dan kemudian secara otomatis melakukan proses pembangunan dan pengujian standar. CI memastikan bahwa seluruh tim dapat meningkatkan kualitas basis kode pada saat yang sama tanpa konflik. Ini juga memastikan bahwa cacat kode ditemukan sedini mungkin. Sebaiknya, proses CI harus dijalankan setiap kali kode tersebut diterapkan atau diperiksa. Paling tidak, proses ini harus berjalan sekali sehari.

Pertimbangkan untuk mengadopsi model pengembangan berbasis batang. Dalam model ini, pengembang melakukan penerapan pada satu cabang (batang). Ada persyaratan bahwa penerapan tidak pernah menghentikan pembangunan. Model ini memfasilitasi CI, karena semua pekerjaan fitur dilakukan di batang, dan semua konflik penggabungan diselesaikan saat penerapan terjadi.

Pertimbangkan untuk menggunakan pengiriman berkelanjutan. Pengiriman berkelanjutan (CD) adalah praktik untuk memastikan bahwa kode selalu siap untuk disebarkan, dengan secara otomatis membangun, menguji, dan menyebarkan kode ke lingkungan seperti produksi. Menambahkan pengiriman berkelanjutan untuk membuat alur CI/CD penuh akan membantu Anda mendeteksi cacat kode sesegera mungkin. Hal ini juga memastikan bahwa pembaruan yang diuji dengan benar dapat dirilis dalam waktu singkat.

Penyebaran berkelanjutan adalah proses tambahan yang secara otomatis mengambil pembaruan apa pun yang telah melewati alur CI/CD dan menyebarkannya ke dalam produksi. Penyebaran berkelanjutan memerlukan pengujian otomatis yang mumpuni dan perencanaan proses lanjutan. Hal ini mungkin tidak sesuai untuk semua tim.

Buat perubahan kecil secara bertambah bertahap. Perubahan kode yang besar memiliki potensi yang lebih besar untuk memperkenalkan bug. Jika memungkinkan, pertahankan agar perubahannya selalu kecil. Tindakan ini membatasi efek potensial dari setiap perubahan, dan lebih memudahkan Anda untuk memahami dan men-debug masalah apa pun.

Kontrol eksposur terhadap perubahan. Pastikan Anda mengontrol kapan pembaruan dapat dilihat oleh pengguna akhir. Pertimbangkan untuk menggunakan pengalih fitur guna mengontrol kapan fitur diaktifkan untuk pengguna akhir.

Implementasikan strategi manajemen rilis untuk mengurangi risiko penyebaran. Menyebarkan pembaruan aplikasi ke produksi selalu mengandung beberapa risiko. Untuk meminimalkan risiko ini, gunakan strategi seperti rilis Kenari atau penyebaran biru-hijau untuk menyebarkan pembaruan ke subset pengguna. Konfirmasikan pembaruan berfungsi seperti yang diharapkan, lalu luncurkan pembaruan ke seluruh sistem.

Dokumentasikan semua perubahan. Pembaruan dan perubahan konfigurasi kecil dapat menjadi sumber kebingungan dan konflik penerapan versi. Selalu simpan catatan yang jelas tentang semua perubahan, sekecil apa pun perubahannya. Catat semua yang berubah, termasuk patch yang diterapkan, perubahan kebijakan, dan perubahan konfigurasi. (Jangan sertakan data sensitif dalam log ini. Misalnya, catat bahwa kredensial telah diperbarui, dan siapa yang membuat perubahan, tetapi tidak merekam kredensial yang diperbarui.) Catatan perubahan harus terlihat oleh seluruh tim.

Pertimbangkan untuk membuat infrastruktur tidak bisa diubah. Infrastruktur yang tidak dapat diubah didasarkan pada prinsip bahwa Anda tidak boleh memodifikasi infrastruktur setelah disebarkan ke produksi. Jika tidak, Anda bisa memasuki keadaan di mana perubahan ad hoc telah diterapkan, sehingga sulit untuk mengetahui dengan tepat apa yang berubah. Infrastruktur yang tidak dapat diubah bekerja dengan mengganti seluruh server sebagai bagian dari penyebaran baru. Ini memungkinkan kode dan lingkungan hosting untuk diuji dan disebarkan sebagai blok. Setelah disebarkan, komponen infrastruktur tidak dimodifikasi hingga siklus pembangunan dan penyebaran berikutnya.

Pemantauan

Buat agar sistem dapat diamati. Tim operasi harus selalu memiliki visibilitas yang jelas terhadap kesehatan dan status sistem atau layanan. Siapkan titik akhir kesehatan eksternal untuk memantau status, dan pastikan bahwa aplikasi dikodekan untuk menginstrumentasi metrik operasi. Gunakan skema umum dan konsisten yang membantu Anda menghubungkan peristiwa di seluruh sistem. Azure Diagnostics dan Application Insights adalah metode standar untuk melacak kesehatan dan status sumber daya Azure. Azure Monitor juga menyediakan pemantauan dan manajemen terpusat untuk solusi cloud atau hibrid.

Mengagregasi dan menghubungkan log dan metrik. Sistem telemetri yang diinstrumentasi dengan benar menyediakan sejumlah besar data performa mentah dan log peristiwa. Pastikan bahwa telemetri dan data log diproses dan dihubungkan segera, sehingga staf operasi selalu memiliki gambaran terkini tentang kesehatan sistem. Atur dan tampilkan data dengan cara yang memberikan tampilan kohesif tentang masalah apa pun, sehingga jika memungkinkan, akan jelas saat beberapa peristiwa saling terkait.

Konsultasikan kebijakan penyimpanan perusahaan Anda untuk persyaratan tentang bagaimana data diproses dan berapa lama data harus disimpan.

Implementasikan peringatan dan pemberitahuan otomatis. Siapkan alat pemantauan seperti Azure Monitor untuk mendeteksi pola atau kondisi yang menunjukkan potensi masalah atau masalah saat ini. Kirim peringatan ke anggota tim yang dapat mengatasi masalah ini. Setel peringatan untuk menghindari positif palsu.

Pantau kedaluwarsa aset dan sumber daya. Beberapa sumber daya dan aset, seperti sertifikat, telah kedaluwarsa. Pastikan untuk melacak aset mana yang kedaluwarsa, kapan kedaluwarsanya, serta layanan atau fitur apa yang bergantung padanya. Gunakan proses otomatis untuk memantau aset ini. Beri tahu tim operasi sebelum aset kedaluwarsa, dan eskalasikan jika kedaluwarsa mengancam akan mengganggu aplikasi.

Manajemen

Otomatiskan tugas operasi. Penanganan proses operasi berulang secara manual rawan kesalahan. Otomatiskan tugas-tugas ini jika memungkinkan untuk memastikan eksekusi dan kualitas yang konsisten. Kode yang mengimplementasikan otomatisasi harus diterapkan versinya dalam kontrol kode sumber. Seperti halnya kode lainnya, alat otomatisasi harus diuji.

Ambil pendekatan infrastruktur sebagai kode untuk provisi. Minimalkan jumlah konfigurasi manual yang diperlukan untuk memprovisikan sumber daya. Sebagai gantinya, gunakan skrip dan template Azure Resource Manager. Simpan skrip dan template dalam kontrol sumber, seperti kode lain yang Anda kelola.

Pertimbangkan untuk menggunakan kontainer. Kontainer menyediakan antarmuka berbasis paket standar untuk menyebarkan aplikasi. Saat Anda menggunakan kontainer, Anda menyebarkan aplikasi dengan menggunakan paket mandiri yang mencakup perangkat lunak, dependensi, dan file apa pun yang diperlukan untuk menjalankan aplikasi. Hal ini sangat menyederhanakan proses penyebaran.

Kontainer juga membuat lapisan abstraksi antara aplikasi dan sistem operasi yang mendasarinya, yang memberikan konsistensi di seluruh lingkungan. Abstraksi ini juga dapat mengisolasi kontainer dari proses atau aplikasi lain yang berjalan pada host.

Implementasikan ketahanan dan penyembuhan diri. Ketahanan adalah kemampuan aplikasi untuk pulih dari kegagalan. Strategi untuk ketahanan termasuk mencoba kembali kegagalan sementara, dan melakukan failover ke instans sekunder atau bahkan ke wilayah lain. Untuk informasi selengkapnya, lihat Merancang aplikasi Azure yang andal. Instrumentasikan aplikasi Anda sehingga masalah segera dilaporkan dan Anda dapat mengelola pemadaman atau kegagalan sistem lainnya.

Miliki panduan operasi. Panduan operasi atau runbook mendokumentasikan informasi prosedur dan manajemen yang diperlukan staf operasi untuk memelihara sistem. Dokumentasikan juga skenario operasi dan rencana mitigasi yang mungkin terjadi selama kegagalan atau gangguan lain pada layanan Anda. Buat dokumentasi ini selama proses pengembangan, dan terus perbarui setelahnya. Ini adalah dokumen hidup, dan harus ditinjau, diuji, dan ditingkatkan secara teratur.

Dokumentasi bersama sangat penting. Dorong anggota tim untuk berkontribusi dan berbagi pengetahuan. Seluruh tim harus memiliki akses ke dokumen. Permudah siapa saja dalam tim untuk membantu memperbarui dokumen.

Dokumentasikan prosedur panggilan. Pastikan tugas, jadwal, dan prosedur panggilan didokumentasikan dan dibagikan kepada semua anggota tim. Selalu perbarui informasi ini.

Prosedur eskalasi dokumen untuk dependensi pihak ketiga. Jika aplikasi Anda bergantung pada layanan pihak ketiga eksternal yang tidak Anda kontrol secara langsung, Anda memerlukan rencana untuk menangani pemadaman. Buat dokumentasi untuk proses mitigasi yang Anda rencanakan. Sertakan kontak dukungan dan jalur eskalasi.

Gunakan manajemen konfigurasi. Perubahan konfigurasi harus direncanakan, terlihat oleh operasi, dan dicatat. Ini bisa berupa database manajemen konfigurasi, atau pendekatan konfigurasi sebagai kode. Konfigurasi harus diaudit secara teratur untuk memastikan bahwa apa yang diharapkan benar-benar terjadi.

Dapatkan paket dukungan Azure dan pahami prosesnya. Azure menawarkan sejumlah paket dukungan. Tentukan rencana yang tepat untuk kebutuhan Anda, dan pastikan seluruh tim tahu cara menggunakannya. Anggota tim harus memahami detail paket, cara kerja proses dukungan, dan cara membuka tiket dukungan dengan Azure. Jika Anda memperkirakan adanya peristiwa berskala tinggi, dukungan Azure dapat membantu Anda meningkatkan batas layanan. Untuk informasi selengkapnya, lihat FAQ Dukungan Azure.

Ikuti prinsip hak istimewa paling sedikit saat memberikan akses ke sumber daya. Kelola akses ke sumber daya dengan hati-hati. Akses harus ditolak secara default, kecuali jika pengguna secara eksplisit diberi akses ke sumber daya. Hanya beri pengguna akses ke apa yang mereka butuhkan untuk menyelesaikan tugas mereka. Lacak izin pengguna dan lakukan audit keamanan secara rutin.

Gunakan kontrol akses berbasis peran Azure. Penetapan akun pengguna dan akses ke sumber daya tidak boleh menjadi proses manual. Gunakan Kontrol akses berbasis peran Azure (RBAC Azure) untuk memberikan akses berdasarkan identitas dan grup Azure Active Directory.

Gunakan sistem pelacakan bug untuk melacak masalah. Tanpa cara yang baik untuk melacak masalah, Anda dapat melewatkan item, menduplikasi pekerjaan, atau menimbulkan masalah baru begitu saja. Jangan mengandalkan komunikasi orang ke orang informal untuk melacak status bug. Gunakan alat pelacakan bug untuk merekam detail tentang masalah, menetapkan sumber daya untuk mengatasinya, dan menyediakan log audit terkait progres dan status.

Kelola semua sumber daya dalam sistem manajemen perubahan. Semua aspek proses DevOps Anda harus disertakan dalam sistem manajemen dan penerapan versi, sehingga perubahan dapat dengan mudah dilacak dan diaudit. Ini termasuk kode, infrastruktur, konfigurasi, dokumentasi, dan skrip. Perlakukan semua jenis sumber daya ini sebagai kode selama proses pengujian, pembangunan, dan peninjauan.

Gunakan daftar periksa. Buat daftar periksa operasi untuk memastikan proses diikuti. Anda dapat begitu saja melewatkan sesuatu dalam panduan yang besar, dan mengikuti daftar periksa dapat memaksa perhatian pada detail yang mungkin terlewatkan. Pertahankan daftar periksa, dan terus cari cara untuk mengotomatisasi tugas dan menyederhanakan proses.

Langkah berikutnya