Dokumentasi infrastruktur internal yang kuat melindungi perusahaan Anda dari gangguan, audit, dan insiden keamanan. Dengan Trupeer, Anda dapat menghemat waktu berjam-jam untuk dokumentasi infrastruktur dengan memulai dari template gratis, menyesuaikannya dengan panduan brand, dan mengubah dokumentasi menjadi video walkthrough untuk tim TI dan MSP.

Kebanyakan dokumentasi infrastruktur ditulis sekali, selama sebuah proyek, dan menjadi keliru dalam enam bulan. Dokumentasi itu tetap ada di wiki, tidak ada yang mempercayainya, dan saat insiden berikutnya seseorang membacanya, ragu, lalu menelepon orang yang benar-benar tahu.

Solusinya bukan menambah dokumentasi. Solusinya adalah mengurangi dokumentasi yang tetap benar, dipilih dengan bertanya apa yang sebenarnya dibutuhkan seseorang pada pukul tiga pagi.

Unduh template dokumentasi infrastruktur

Gratis, dapat diedit, tanpa watermark. Excel mengerjakan sebagian besar pekerjaan di sini, karena dokumentasi infrastruktur sebagian besar adalah data terstruktur yang berpura-pura menjadi prosa.

Dokumentasi apa yang Anda butuhkan?

Cara menyesuaikan template ini di Trupeer

Langkah 1: Buka Bagian Templates

Buka bagian Templates dari navigasi utama.

Langkah 2: Pilih dan Buka sebuah Template

Klik pada template apa pun yang ingin Anda gunakan untuk membukanya.

Langkah 3: Perluas Tampilan Template

Jika diperlukan, perluas tampilan template untuk melihat tata letak dan detailnya dengan jelas.

Langkah 4: Edit Template

Klik Edit untuk mulai memodifikasi template yang dipilih.

Di dalam editor, Anda bisa:

• Menambahkan bagian baru

• Menetapkan atau memperbarui aturan pemformatan

• Menambahkan logo dan menyesuaikan posisinya serta pengaturan terkait

Langkah 5: Simpan Template yang Anda Sesuaikan

Setelah membuat semua perubahan yang diperlukan, klik Save untuk menyimpan template yang diperbarui sebagai milik Anda.

Langkah 6: Pratinjau dan Penyempurnaan Template

Saat Anda ingin melihat seperti apa tampilan template yang Anda sesuaikan, buka Preview.

Dari layar pratinjau, Anda dapat terus melakukan penyesuaian secara langsung jika diperlukan, sehingga template tampil persis seperti yang Anda inginkan.

Dengan template dokumentasi infrastruktur internal, Anda bisa:

• Menghemat waktu untuk penulisan: Lewati halaman kosong dengan struktur yang dibangun untuk infrastruktur TI.

• Meningkatkan postur keamanan: Kolom bawaan memastikan praktik penanganan kredensial yang aman.

• Tetap sesuai brand: Terapkan logo, font, dan warna Anda menggunakan brand kit Trupeer.

• Kurangi waktu henti: Dokumentasi yang jelas mengurangi MTTR saat insiden.

• Tetap siap audit: Selaras dengan SOC 2, ISO 27001, dan kerangka kerja serupa.

• Menjangkau tim global: Terjemahkan dokumentasi ke 65+ bahasa hanya dengan satu klik.

Uji coba pukul 3 pagi

Satu-satunya uji coba yang benar-benar penting untuk dokumentasi infrastruktur.

Bayangkan ada insiden pada pukul tiga pagi. Orang yang membangun sistem sedang berada di pesawat. Ada orang yang kompeten namun belum familiar yang melihat dokumentasi Anda. Bisakah mereka mengetahui apa yang rusak, apa yang bergantung padanya, apa yang terjadi jika mereka menyalakannya ulang, dan siapa yang harus di-escalate?

Semua hal yang membantu itu layak ditulis. Sisanya bersifat opsional, dan dokumentasi opsional adalah yang mengencerkan bagian yang berguna serta menghabiskan anggaran pemeliharaan.

Terapkan tanpa ampun. Riwayat detail tentang mengapa sebuah teknologi dipilih pada tahun 2021 tidak lulus. Catatan yang mengatakan layanan ini harus dimulai setelah database dan sebelum API gateway tidak lulus.

Apa yang lulus uji coba pukul 3 pagi

• Apa yang ada. Sistem, server, layanan, dengan satu kalimat tentang apa yang dilakukan masing-masing.

• Di mana ia berada. Penyedia cloud dan region, atau lokasi fisik dan rak.

• Apa yang bergantung padanya, dan apa yang menjadi tumpuannya. Hal paling berharga dalam dokumentasi infrastruktur.

• Cara menghubunginya. Hostname, alamat, konsol, meski tidak pernah kredensial.

• Seperti apa kondisi normal. Agar orang yang belum familiar bisa mengetahui apakah sesuatu benar-benar bermasalah.

• Apa yang membuatnya rusak. Mode kegagalan yang diketahui dan gejalanya.

• Cara menyalakannya ulang dengan aman, termasuk urutan dan apa pun yang harus dilakukan terlebih dahulu.

• Siapa yang memilikinya, dan jalur eskalasi dengan detail kontak yang benar.

• Seberapa luas dampaknya. Apa yang akan mati jika ini terjadi.

Apa yang biasanya tidak lulus

Ditulis untuk kelengkapan, bukan untuk digunakan, sehingga tidak layak dipelihara.

Dump konfigurasi lengkap yang sudah usang sehari setelah diekspor. Rincian alasan untuk keputusan masa lalu, yang seharusnya ada di architecture decision record, bukan dokumentasi operasional. Setiap parameter dari setiap sistem saat hanya segelintir yang penting secara operasional. Screenshot konsol yang cepat menjadi tua dan jarang membantu. Dan apa pun yang menduplikasi sumber kebenaran di tempat lain, karena dua salinan berarti satu pasti salah dan Anda tidak bisa menentukan yang mana.

Prinsip umumnya: jika bisa ditemukan dari sistem lebih cepat daripada dibaca dari dokumen, jangan didokumentasikan.

Inventaris infrastruktur

Fondasinya. Satu baris per sistem atau layanan.

Kolom terakhir adalah yang paling sering diabaikan oleh sebagian besar inventaris, dan yang menentukan apakah siapa pun mempercayai dokumen tersebut. Baris yang tidak pernah dicek selama dua tahun seharusnya terlihat tidak dipercaya, bukan salah secara diam-diam.

Tier kritikalitas

Tetapkan, karena tier ini menentukan seberapa banyak dokumentasi yang layak diterima setiap sistem.

Kebanyakan organisasi mendokumentasikan tier 3 dengan kedalaman yang sama seperti tier 1, kehabisan tenaga, lalu berakhir dengan semuanya terdokumentasi setengah-setengah. Dokumentasikan tier 1 dengan benar dan biarkan tier 3 menjadi satu baris.

Dependensi

Bagian paling berharga dan paling sering diabaikan dalam dokumentasi infrastruktur.

Saat insiden, pertanyaannya jarang apa yang rusak. Pertanyaannya adalah apa lagi yang terdampak, dan apa yang dibutuhkan komponen ini agar bisa kembali. Keduanya tidak bisa ditemukan hanya dari daftar server.

Dokumentasikan dependensi dalam dua arah:

Ada dua hal yang membuat ini berguna. Urutan startup, karena menyalakan ulang hal-hal dengan urutan yang salah mengubah insiden singkat menjadi insiden panjang. Dan apakah dependensinya bersifat hard atau soft, karena layanan yang menurun secara bertahap adalah masalah yang sangat berbeda dibanding layanan yang langsung gagal.

Sertakan dependensi eksternal. Penyedia pembayaran, penyedia identitas, DNS, certificate authority, dan API SaaS menyebabkan gangguan yang tidak bisa Anda perbaiki, dan mengetahui hal itu dengan cepat sangat berharga pada pukul 3 pagi.

Dokumentasi jaringan

Masa berlaku sertifikat layak mendapat perhatian khusus. Ini menyebabkan gangguan yang sepenuhnya dapat diprediksi, sepenuhnya dapat dicegah, dan secara tidak proporsional kemungkinan besar terjadi pada akhir pekan. Dokumentasikan kapan yang kedaluwarsa, siapa yang memperpanjang, dan apakah perpanjangan diautomasi.

Runbook

Dokumen yang benar-benar dibuka seseorang saat insiden.

Bagian "apa yang tidak boleh dilakukan" jarang dan bernilai. Setiap sistem yang matang memiliki tindakan yang tampak masuk akal namun justru memperburuk insiden: menyalakan ulang dengan urutan yang salah, menghapus cache yang butuh enam jam untuk dibangun ulang, melakukan failover saat secondary berada di belakang.

Tulis runbook untuk sistem tier 1 dan untuk apa pun yang pernah menyebabkan insiden. Bukan untuk semuanya.

Akses dan kredensial

Bagian di mana dokumentasi justru menimbulkan dampak buruk, bukan mencegahnya.

Jangan pernah menaruh kredensial dalam dokumentasi. Bukan kata sandi, bukan kunci API, bukan string koneksi yang menyertakan rahasia, bukan private key. Bukan di wiki, bukan di file Excel, bukan "sementara".

Dokumentasikan metode akses. Sistem mana yang menyimpan kredensial, siapa yang bisa memberikan akses, dan bagaimana seseorang memintanya pada pukul 3 pagi. Itulah yang benar-benar dibutuhkan orang tersebut, dan aman untuk dituliskan.

Lalu dokumentasikan prosedur break-glass dengan benar, karena akses darurat yang tidak tersedia saat keadaan darurat adalah kegagalan yang umum dan bisa dihindari.

Pemulihan bencana

Apa yang harus dimuat dalam dokumentasi DR agar bernilai.

Recovery time dan recovery point objectives untuk setiap sistem tier 1, disepakati dengan bisnis, bukan diasumsikan oleh TI. Apa sebenarnya prosedur pemulihannya, langkah demi langkah. Di mana backup berada, dan yang paling penting kapan restore terakhir berhasil diuji. Siapa yang menyatakan bencana dan siapa yang menjalankan rencana. Bagaimana tim berkomunikasi saat sistem normal mati, karena rencana DR yang hanya tersimpan di sistem yang sedang mati adalah aib yang familiar.

Satu baris paling penting dalam dokumen DR mana pun adalah tanggal uji coba restore terakhir yang berhasil. Backup yang belum pernah dipulihkan adalah sebuah hipotesis.

Diagram

Infrastruktur mendapat manfaat dari diagram lebih dari kebanyakan dokumentasi, dan diagram cepat menjadi usang.

• Satu diagram tingkat tinggi yang menunjukkan komponen utama dan bagaimana semuanya terhubung. Ini yang benar-benar digunakan orang.

• Topologi jaringan, jika lingkungan Anda cukup kompleks sehingga memerlukannya.

• Alur data, terutama jika melintasi batas kepercayaan atau yurisdiksi.

• Jaga agar tetap sederhana. Diagram yang tidak bisa dibaca orang sekilas saat insiden adalah dekorasi.

• Beri tanggal, dan cantumkan pemilik di diagram.

• Pilih diagram-as-code jika tim Anda akan memeliharanya, karena diagram dalam format teks yang dikontrol versi akan diperbarui bersama perubahan, bukan setelahnya.

Diagram yang salah lebih buruk daripada tidak ada diagram, karena orang lebih mempercayai gambar daripada prosa.

Menjaganya tetap akurat

Masalahnya sepenuhnya, dan alasan mengapa sebagian besar dokumentasi infrastruktur gagal.

• Dokumentasikan lebih sedikit. Akurasi berbanding terbalik dengan volume. Lima belas halaman yang akurat lebih baik daripada dua ratus halaman yang usang.

• Pasangkan pembaruan dokumentasi dengan proses perubahan. Perubahan yang mengubah infrastruktur tidak lengkap sampai dokumentasi mencerminkannya. Ini satu-satunya mekanisme yang benar-benar bekerja secara andal.

• Otomatiskan apa yang bisa ditemukan. Inventaris, alamat, konfigurasi, dan topologi sering kali bisa dihasilkan. Dokumentasi hasil generasi tidak akan menjadi usang seperti dokumentasi tulisan tangan.

• Tulis manual hanya apa yang tidak bisa ditemukan. Tujuan, kepemilikan, kritikalitas, dependensi, mode kegagalan yang diketahui, apa yang tidak boleh dilakukan. Mesin tidak bisa menyimpulkan semuanya.

• Beri tanggal semuanya, dan tampilkan tanggalnya dengan jelas. Tanggal terakhir yang terlihat membantu pembaca menilai tingkat kepercayaan.

• Review sesuai jadwal berdasarkan tier, setiap kuartal untuk tier 1.

• Perbaiki saat insiden. Saat seseorang menemukan dokumentasi itu salah, saat itulah mereka memiliki pengetahuan untuk memperbaikinya. Jadikan tugas lima menit, bukan tiket.

Otomasi dan discovery

Layak diinvestasikan, karena ini menghilangkan mode kegagalan terbesar.

Database manajemen konfigurasi, inventaris penyedia cloud, repositori infrastructure-as-code, dan alat network discovery semuanya dapat menghasilkan informasi kondisi terkini yang akurat secara berkelanjutan. Apa pun yang bisa mereka hasilkan seharusnya tidak dipelihara secara manual.

Pembagian yang berhasil: mesin mendokumentasikan apa yang ada, manusia mendokumentasikan apa artinya. Inventaris yang dihasilkan otomatis memberi tahu Anda bahwa sebuah server ada dan apa yang terpasang di dalamnya. Hanya orang yang bisa memberi tahu bahwa itu adalah yang tidak boleh di-reboot antara pukul 2 pagi dan 4 pagi karena batch run.

Jika infrastruktur didefinisikan sebagai kode, maka kodenya adalah dokumentasi tentang apa yang ada. Yang tersisa untuk ditulis adalah maksud, pengetahuan operasional, dan mode kegagalan.

Siapa yang memilikinya

Tetapkan kepemilikan per sistem, bukan menjadikan dokumentasi sebagai tugas satu orang, yang tidak pernah bertahan setelah orang itu pergi.

Tim yang mengoperasikan sebuah sistem memiliki dokumentasinya. Seseorang yang disebutkan namanya memiliki standar keseluruhan, template, dan ritme review. Dan proses perubahan memastikan pembaruan, karena kepemilikan tanpa mekanisme adalah niat.

Pola kegagalannya adalah pemilik dokumentasi yang mengejar semua orang lain. Itu bekerja sekitar dua bulan.

Menguji dokumentasi

Setara dengan uji coba restore, dan sama-sama diabaikan.

Ambil seseorang yang tidak membangun sistem, berikan hanya dokumentasinya, lalu minta mereka menyelesaikan tugas operasional rutin. Restart terkontrol, failover, restore ke lingkungan pengujian.

Semua hal yang tidak bisa mereka lakukan dari dokumentasi adalah celah. Semua yang mereka lakukan salah adalah cacat. Ini tidak nyaman, tetapi ini satu-satunya cara andal untuk mengetahui apakah dokumentasi akan bekerja pada pukul 3 pagi, karena orang yang menulisnya selalu bisa mengisi celah dari ingatan.

Lakukan ini untuk sistem tier 1 setidaknya setiap tahun, idealnya sebagai bagian dari game day atau latihan DR.

Praktik terbaik

• Terapkan uji coba pukul 3 pagi ke semuanya sebelum menulisnya.

• Dokumentasikan tier 1 dengan benar dan tier 3 secara minimal.

• Dependensi dalam dua arah, dengan urutan startup.

• Jangan pernah kredensial, selalu metode akses.

• Tanggal terakhir diverifikasi pada setiap catatan.

• Otomatiskan apa pun yang bisa ditemukan, tulis manual hanya maksud dan pengetahuan operasional.

• Pembaruan dokumentasi diberlakukan oleh proses perubahan.

• Runbook mencakup apa yang tidak boleh dilakukan.

• Uji coba restore diberi tanggal dalam rencana DR.

• Uji dokumentasi dengan seseorang yang belum familiar, setiap tahun.

Kesalahan umum

• Kredensial di wiki.

• Semua didokumentasikan dengan kedalaman yang sama, jadi tidak ada yang dipelihara.

• Dependensi didokumentasikan hanya dalam satu arah.

• Tidak ada urutan startup, sehingga pemulihan memakan waktu lebih lama daripada gangguan.

• Dump konfigurasi yang usang saat tiba.

• Diagram tanpa tanggal dan tanpa pemilik, dipercaya lama setelah tidak lagi benar.

• Dokumentasi sebagai output proyek, tidak pernah diperbarui setelahnya.

• Satu orang yang secara nominal bertanggung jawab untuk semuanya.

• Rencana DR disimpan di infrastruktur yang dicakupnya.

• Backup didokumentasikan, restore tidak pernah diuji.

• Tidak ada tanggal terakhir diverifikasi, sehingga pembaca tidak bisa menilai apa yang harus dipercaya.

• Ditulis oleh orang yang membangunnya, diuji oleh tidak ada siapa pun.

Tangkap apa yang hanya diketahui oleh orang yang membangunnya

Buka template di Trupeer AI, terapkan brand kit Anda agar dokumentasi sesuai standar Anda, dan edit bagian apa pun secara langsung. Penyiapannya ada di panduan template.

Otomasi mencakup apa yang ada. Yang tidak bisa ditangkap adalah pengetahuan operasional: urutan hal-hal kembali, pengecekan yang Anda lakukan sebelum melakukan failover, dan alasan tidak ada yang memulai ulang layanan itu pada hari Selasa.

Pengetahuan itu ada pada satu atau dua orang dan akan hilang saat mereka pergi. Minta mereka melakukan walkthrough failover atau restore sambil merekam, dan Trupeer AI akan menghasilkan runbook tertulis serta video walkthrough yang dinarasikan dari sesi yang sama, dalam urutan yang benar-benar mereka lakukan, bukan urutan yang mungkin mereka ingat saat menuliskannya.

Selain itu, ini juga memakan waktu mereka lebih sedikit daripada menulis, yang penting, karena alasan pengetahuan operasional tetap tidak terdokumentasi adalah orang yang memilikinya adalah yang paling sibuk. Terjemahkan ke 65+ bahasa untuk tim yang tersebar, dan simpan set tersebut di knowledge base Anda di samping runbook.

Rekam. Branding. Terjemahkan. Trupeer-kan.

Pertanyaan yang Sering Diajukan

Apakah ada template dokumentasi infrastruktur gratis di Word?

Ya. Word menyimpan runbook, ringkasan arsitektur, dan rencana DR, bagian yang benar-benar bersifat naratif. Unduh gratis, tanpa pendaftaran, tanpa watermark.

Apakah ada template dokumentasi infrastruktur gratis di Excel?

Ya, dan Excel mengerjakan sebagian besar pekerjaan. Template ini mencakup inventaris sistem dengan tier kritikalitas dan tanggal terakhir diverifikasi, matriks dependensi dalam dua arah, detail jaringan, pelacakan masa berlaku sertifikat, serta jadwal review.

Apakah ada template dokumentasi infrastruktur gratis di PDF?

Ya, dalam bentuk versi yang disetujui dan untuk apa pun yang diminta auditor atau klien untuk dilihat. Simpan salinan kerja agar tetap bisa diedit, karena dokumentasi infrastruktur yang tidak bisa diperbarui dengan cepat tidak akan diperbarui.

Bisakah saya mengunduh template dokumentasi infrastruktur gratis?

Ya, setiap format adalah unduhan gratis tanpa akun yang diperlukan dan tanpa atribusi.

Apakah ada template dokumentasi TI gratis?

Ya. Halaman ini membahas infrastruktur secara khusus. Untuk dokumentasi TI yang lebih luas, termasuk proses, kebijakan, dan materi panduan, lihat contoh dan template dokumentasi TI, dan untuk prosedur TI, lihat template SOP TI.

Apakah ada template dokumentasi TI di Word?

Ya, di halaman contoh dan template dokumentasi TI. Halaman ini lebih sempit, mencakup sistem, jaringan, dan dependensi yang membentuk infrastruktur Anda.

Apakah ada template dokumentasi proyek di Word, gratis untuk diunduh?

Ya, di halaman template dokumentasi proyek. Dokumentasi proyek mencakup ruang lingkup, rencana, dan deliverables sebuah proyek, sementara dokumentasi infrastruktur mencakup apa yang ada di produksi apa pun proyek yang membangunnya.

Apa itu dokumentasi infrastruktur TI?

Catatan tentang sistem, jaringan, layanan, dan dependensi yang membentuk lingkungan Anda, beserta pengetahuan operasional yang diperlukan untuk menjalankan dan memulihkannya. Dokumentasi ini mencakup apa yang ada, apa yang bergantung pada apa, seperti apa kondisi normal, dan cara merespons saat sesuatu rusak.

Apa yang harus disertakan dalam dokumentasi infrastruktur?

Inventaris sistem dengan pemilik dan kritikalitas, dependensi dalam dua arah dengan urutan startup, detail jaringan dan konektivitas, runbook untuk sistem kritis, metode akses tetapi tidak pernah kredensial, detail backup dan disaster recovery termasuk uji coba restore terakhir yang berhasil, serta tanggal terakhir diverifikasi untuk semuanya.

Bagaimana cara menjaga dokumentasi infrastruktur tetap up to date?

Dokumentasikan lebih sedikit, otomatisasikan apa pun yang bisa ditemukan, dan pasangkan pembaruan dokumentasi dengan proses perubahan Anda agar perubahan tidak dianggap selesai sampai dokumentasi mencerminkannya. Cantumkan tanggal terakhir diverifikasi yang terlihat pada setiap catatan, review berdasarkan tier kritikalitas, dan biarkan siapa pun memperbaiki kesalahan segera daripada mengajukan tiket.

Apakah kredensial harus disimpan dalam dokumentasi?

Tidak. Bukan kata sandi, kunci API, string koneksi, atau private key, di sistem mana pun, baik sementara maupun lainnya. Dokumentasikan sebagai gantinya vault atau secrets manager mana yang menyimpan kredensial, siapa yang bisa memberikan akses, dan prosedur break-glass untuk keadaan darurat. Itulah yang benar-benar dibutuhkan seseorang saat insiden, dan aman untuk dituliskan.

Seberapa banyak infrastruktur yang harus Anda dokumentasikan?

Cukup untuk lulus uji coba pukul 3 pagi bagi sistem kritis, dan sangat sedikit untuk sisanya. Sistem tier 1 membutuhkan runbook lengkap, peta dependensi, dan DR yang diuji. Sistem tier 3 membutuhkan satu baris inventaris dan pemilik. Mendokumentasikan semuanya dengan kedalaman yang sama adalah alasan mengapa sebagian besar dokumentasi infrastruktur akhirnya menjadi usang.

Apa itu runbook?

Dokumen operasional untuk satu sistem yang mencakup seperti apa kondisi normal, apa arti alert umum, cara menyalakan ulang dengan aman termasuk urutan dan prasyarat, mode kegagalan yang diketahui, apa yang tidak boleh dilakukan, dan kapan harus melakukan eskalasi. Ini adalah dokumen yang dibuka seseorang saat insiden, dan harus ditulis untuk orang yang kompeten namun belum familiar dengan sistem spesifik tersebut.

Bagaimana cara mendokumentasikan dependensi?

Dalam dua arah, karena saat insiden Anda perlu mengetahui baik apa yang dibutuhkan sistem ini maupun apa yang rusak jika sistem ini berhenti. Sertakan urutan startup, apakah setiap dependensi bersifat hard atau soft, serta dependensi eksternal seperti penyedia identitas, DNS, dan payment processor, yang menyebabkan gangguan yang tidak bisa Anda perbaiki sendiri.

Seberapa sering dokumentasi infrastruktur harus direview?

Berdasarkan tier kritikalitas: setiap kuartal untuk tier 1, dua kali setahun untuk tier 2, dan saat ada perubahan untuk tier 3. Di luar review terjadwal, proses perubahan harus memaksa pembaruan, dan siapa pun yang menemukan kesalahan saat insiden harus bisa memperbaikinya segera.

Bagaimana cara mengetahui apakah dokumentasi Anda benar-benar berfungsi?

Uji. Beri seseorang yang tidak membangun sistem hanya dokumentasinya, lalu minta mereka melakukan tugas operasional rutin seperti restart terkontrol atau restore ke lingkungan pengujian. Apa pun yang tidak bisa mereka lakukan adalah celah. Melakukan ini setiap tahun untuk sistem tier 1 setara dengan uji coba restore, dan sama seringnya dilewatkan.

Bisakah saya menyesuaikan template dokumentasi infrastruktur ini?

Ya, setiap versi sepenuhnya dapat diedit. Sesuaikan tier kritikalitas dan kolom dengan lingkungan Anda. Dua hal yang layak dipertahankan adalah tanggal terakhir diverifikasi dan pemetaan dependensi dua arah, karena keduanya yang menentukan apakah dokumentasi dipercaya dan apakah membantu saat insiden.

Template terkait

• contoh dan template dokumentasi TI

• template SOP TI

• template dokumentasi teknis

• template dokumentasi perangkat lunak

• template dokumentasi proyek

• template SOP knowledge transfer

• template dokumen serah terima

• template metode prosedur

• template kebijakan perlindungan data