Memahami beban kerja

Untuk menerapkan kerangka kerja, mulailah dengan memahami beban kerja yang ingin Anda analisis. Diagram arsitektur sistem menyediakan titik awal untuk mendokumentasikan detail sistem yang paling relevan. Namun, mencoba menganalisis seluruh beban kerja bisa menjadi rumit, karena banyak sistem memiliki banyak komponen dan interaksi. Sebagai gantinya, kami menyarankan Anda untuk fokus padacerita pengguna, yanginformal, penjelasan umum tentang fitur perangkat lunak yang ditulis dari perspektif pengguna akhir. Tujuan mereka adalah untuk mengartikulasikan bagaimana fitur perangkat lunak memberikan nilai kepada pelanggan. Anda kemudian dapat memodelkan cerita pengguna ini dengan diagram arsitektur dan diagram aliran data untuk membuatnya lebih mudah untuk menilai komponen teknis yang menyediakan fungsionalitas bisnis yang dijelaskan. Misalnya, solusi pembelian game seluler dalam aplikasi mungkin memiliki dua cerita pengguna, “membeli kredit dalam aplikasi” dan “memperoleh pengembalian dana dalam aplikasi,” seperti yang ditunjukkan pada diagram berikut. (Contoh arsitektur ini menyoroti bagaimana Anda dapat menguraikan sistem menjadi cerita pengguna; itu tidak dimaksudkan untuk mewakili aplikasi yang sangat tangguh.)

Setiap cerita pengguna terdiri dari empat komponen umum: kode dan konfigurasi, infrastruktur, penyimpanan data, dan dependensi eksternal. Diagram Anda harus mencakup semua komponen ini dan mencerminkan interaksi antar komponen. Misalnya, jika ada beban berlebihan pada titik akhir Amazon API Gateway Anda, pertimbangkan bagaimana beban tersebut mengalir ke komponen lain dalam sistem, sepertiAWS Lambdafungsi atau tabel Amazon DynamoDB. Melacak interaksi ini membantu Anda memahami bagaimana mode kegagalan dapat memengaruhi cerita pengguna. Anda dapat menangkap aliran ini secara visual dengan diagram aliran data atau dengan menggunakan panah aliran sederhana dalam diagram arsitektur, seperti pada ilustrasi sebelumnya. Untuk setiap komponen, pertimbangkan untuk menangkap detail seperti jenis informasi yang dikirimkan, informasi yang diterima, apakah komunikasi itu sinkron atau asinkron, dan batas kesalahan mana yang dilintasi. Dalam contoh, tabel DynamoDB dibagikan di kedua cerita pengguna, seperti yang dapat Anda lihat oleh panah yang menunjukkan bahwa komponen Lambda dalam cerita pengembalian dana dalam aplikasi mengakses tabel DynamoDB dalam cerita pembelian dalam aplikasi. Ini berarti bahwa kegagalan yang disebabkan oleh kisah pengguna pembelian dalam aplikasi dapat mengalir ke kisah pengguna pengembalian dana dalam aplikasi sebagai akibat dari nasib bersama.

Selain itu, penting untuk memahami konfigurasi dasar untuk setiap komponen. Konfigurasi dasar mengidentifikasi kendala seperti jumlah rata-rata dan maksimum transaksi per detik, ukuran maksimum muatan, batas waktu klien, dan kuota layanan default atau saat ini untuk sumber daya. Jika Anda memodelkan desain baru, kami sarankan Anda mendokumentasikan persyaratan fungsional untuk desain dan mempertimbangkan batasannya. Ini membantu Anda memahami bagaimana mode kegagalan dapat bermanifestasi dalam komponen.

Terakhir, Anda harus memprioritaskan cerita pengguna berdasarkan nilai bisnis yang mereka berikan. Prioritas ini membantu Anda fokus pada fungsionalitas beban kerja Anda yang paling penting terlebih dahulu. Anda kemudian dapat memfokuskan analisis Anda pada komponen beban kerja yang merupakan bagian dari jalur kritis untuk fungsionalitas itu, dan menyadari nilai dari memanfaatkan kerangka kerja lebih cepat. Saat Anda mengulangi proses, Anda dapat memeriksa cerita pengguna tambahan pada prioritas yang berbeda.