Praktik terbaik untuk fase build

Rekomendasi di bagian ini membantu memastikan fase pembangunan yang lebih lancar untuk proyek Anda. Fase build mencakup aktivitas kode, pengembangan, penyebaran, dan implementasi. Ini sering terdiri dari tinjauan desain dan sesi persetujuan, pertemuan awal untuk menyelaraskan apa yang sedang dibangun, garis waktu, dan kriteria keluar. Ini adalah fase di mana kode ditulis, peer-review, dan digunakan untuk semua layanan. AWS

Rekomendasi berikut juga mencakup kegiatan pengujian atau verifikasi.

Selenggarakan pertemuan stand-up harian

Pastikan untuk menyelenggarakan pertemuan stand-up harian, apa pun metodologi proyek yang Anda gunakan. Meskipun stand-up harian dikaitkan dengan metodologi tangkas, mereka juga merupakan mekanisme koneksi tim yang sangat berguna untuk metodologi lain, termasuk model air terjun. Anda bahkan dapat menggunakan kerangka kerja proyek hibrida yang mengambil praktik terbaik dari berbagai metodologi.

Pertimbangan:

• Gunakan sesuatu yang ringan seperti papan Jira untuk membuat cerita untuk setiap tugas. Papan ini akan menjadi panduan Anda untuk stand-up harian Anda. Jika tim Anda memiliki bandwidth dan keahlian, Anda juga dapat menggunakan metodologi Scaled Agile Framework (SAFe) dan membuat epos. Namun, sebagian besar tim infrastruktur tidak menginginkan overhead administratif untuk mengelola papan scrum yang kompleks, jadi kami merekomendasikan alat yang ringan. Memiliki papan juga memungkinkan Anda menghasilkan laporan tentang pekerjaan yang dilakukan tim Anda, dan memberi Anda mekanisme untuk mengendalikan ruang lingkup.

• Dalam proyek SAP greenfield, tidak jarang banyak aplikasi SAP atau batas ditambahkan setelah ruang lingkup terkunci. Jika Anda tidak memiliki mekanisme yang baik untuk mengendalikan, memprioritaskan, dan memberikan visibilitas ke ruang lingkup proyek, akan sulit untuk meminta sumber daya tambahan atau memprioritaskan kembali pekerjaan untuk menjaga proyek tetap pada jalurnya.

Gunakan lembar spesifikasi build terpadu

Gunakan spreadsheet spesifikasi build tunggal untuk semua lingkungan dan lanskap. Ini menciptakan satu dokumen yang dapat dengan mudah ditemukan dan dicari. Kami menyarankan Anda mengaktifkan manajemen versi agar mudah pulih dari kecelakaan. Munculkan format bekerja sama dengan tim SAP Basis. Tim Basis melacak detail seputar sistem SAP, dan memiliki satu spesifikasi memastikan bahwa tim cloud internal dapat dengan cepat mengambil kepemilikan dan melihat semua metadata di satu tempat setelah proyek selesai.

Berikut adalah contoh template yang digunakan untuk menangkap metadata build server kunci dengan satu persyaratan server sampel.

Waspadai kuota AWS layanan

Ada kuota pada jumlah virtual CPUs (vCPUs) yang dapat Anda berikan untuk instans Amazon Elastic Compute Cloud EC2 (Amazon). Saat Anda menerapkan EC2 instance, itu memerlukan sejumlah vCPUs, tergantung pada jenis EC2 instancenya. Setiap AWS akun memiliki batas lunak pada jumlah v CPUs yang dapat disediakan untuk itu. Saat Anda menerapkan EC2 instance, batas lunak meningkat secara otomatis sekitar 100-150 v. CPUs Namun, jika Anda mencoba menerapkan beberapa (katakanlah, 20) EC2 instance secara bersamaan, Anda mungkin melebihi batas lunak. Jika Anda merasa mengalami batasan ini, kirimkan permintaan untuk menambah kuota sebelum menerapkan instans EC2 . Ini akan memungkinkan Anda untuk menghindari mencapai batas kuota layanan di tengah penerapan.

Kembangkan strategi rotasi kunci untuk keamanan

AWS Key Management Service (AWS KMS) memudahkan pelanggan untuk membuat dan mengelola kunci kriptografi dan mengontrol penggunaannya di berbagai AWS layanan dan dalam berbagai aplikasi. Untuk implementasi SAP, AWS KMS kunci digunakan untuk mengenkripsi data saat istirahat yang disimpan dalam volume Amazon Elastic Block Store (Amazon EBS) EBS) dan digunakan untuk binari SAP dan sistem file SAP HANA. Kunci KMS juga digunakan untuk data yang disimpan di bucket Amazon Simple Storage Service (Amazon S3) untuk menyimpan media perangkat lunak dan backup, dan dalam sistem file Amazon Elastic File System (Amazon EFS) untuk dan. /usr/sap/trans /sapmnt AWS KMS memberi Anda fleksibilitas untuk menggunakan kunci AWS terkelola atau kunci yang dikelola pelanggan. Kami menyarankan Anda mendokumentasikan dan membagikan strategi dan keputusan manajemen kunci keamanan Anda di awal fase pembuatan. Perubahan kebijakan keamanan di tengah proyek, seperti beralih dari kunci yang dikelola pelanggan ke kunci AWS terkelola, dapat memerlukan pembangunan kembali lengkap lingkungan SAP, yang mungkin memengaruhi jadwal proyek Anda.

Dapatkan buy-in dari semua pemangku kepentingan keamanan pada penggunaan dan rotasi kunci. Pertimbangkan kebijakan rotasi kunci yang ada untuk lingkungan cloud atau lokal dan ubah kebijakan ini untuk digunakan. AWS Jika Anda menghadapi kesulitan mendapatkan konsensus tentang strategi manajemen utama Anda, berikan pelatihan kepada para pembuat keputusan, untuk membantu mereka memahami dasar keamanan dan pertimbangan penetapan level. Membuat keputusan rotasi kunci sebelum lingkungan dibangun sangat penting. Misalnya, jika Anda mengubah dari kunci yang dikelola pelanggan ke kunci AWS terkelola, Anda akan mengalami masalah dengan Amazon EBS, yang tidak mengizinkan perubahan pada kunci enkripsi secara online. Volume EBS harus dibangun kembali dengan kunci baru. Ini mengharuskan membangun kembali instance SAP Anda, yang bukan skenario yang ideal.

Demikian pula, jika proyek Anda menggunakan solusi manajemen kunci eksternal, seperti Vormetric, dan mengimpor materi utama ke dalam AWS KMS, pastikan bahwa pembuat keputusan keamanan Anda mengetahui perbedaan rotasi utama antara kunci dan AWS KMS kunci KMS eksternal (rotasi otomatis). Saat Anda menggunakan dan memutar kunci KMS eksternal sesuai dengan kebijakan keamanan Anda, tidak hanya materi kunci tetapi juga perubahan Nama Sumber Daya Amazon (ARN) kunci, yang berarti bahwa volume EBS harus dibuat ulang, dan seluruh sistem SAP harus menjalani migrasi kecil. Di sisi lain, jika Anda mengaktifkan rotasi otomatis untuk kunci yang dikelola pelanggan atau kunci AWS terkelola AWS KMS, materi utama berubah tetapi ARN kunci tetap sama, yang berarti bahwa volume EBS tidak terpengaruh. Untuk informasi selengkapnya tentang rotasi kunci, lihat Memutar AWS KMS kunci dalam AWS KMS dokumentasi.

Pendekatan keamanan lainnya adalah menggunakan AWS Secrets Manager database dan rotasi kata sandi sistem operasi, yang tersedia melalui dasbor standar. Selain itu, pastikan bahwa peran AWS Identity and Access Management (IAM) untuk lingkungan pemulihan bencana diisolasi dari lingkungan produksi untuk membantu melindungi lingkungan dari aktivitas berbahaya.

Menonaktifkan server yang tidak digunakan

Kami menyarankan Anda untuk menonaktifkan server proof of concept (PoC) segera setelah kegunaannya habis. Menjalankan server yang tidak digunakan bisa mahal. Penting untuk melacak semua server yang Anda buat untuk implementasi SAP greenfield Anda, dan menghentikan dan menonaktifkan server yang tidak Anda gunakan secara aktif selama fase build. Sebelum menonaktifkan server, Anda dapat membuat cadangan Amazon Machine Image (AMI) dari EC2 instans tersebut. Anda kemudian dapat mengembalikan cadangan jika Anda perlu memutar server yang sama persis di masa depan.

Penonaktifan server seharusnya tidak menjadi latihan yang Anda simpan untuk akhir proyek implementasi. Anda harus memantau penggunaan, menghentikan, dan akhirnya menghancurkan server yang tidak digunakan sepanjang umur proyek Anda dan setelah Anda menyelesaikan implementasi, dalam fase pemeliharaan atau operasional. Pastikan untuk mengatur proses di awal untuk mengajarkan anggota tim SAP Basis untuk menonaktifkan server ini, karena biaya akan menumpuk dengan cepat.