Kongsi melalui

Cadangan untuk mereka bentuk untuk kesederhanaan dan kecekapan

Terpakai kepada cadangan senarai semak Kebolehpercayaan Well-Architected ini Power Platform :

RE:01 Reka bentuk beban kerja anda agar sejajar dengan objektif perniagaan dan mengelakkan kerumitan atau overhed yang tidak perlu. Gunakan pendekatan praktikal dan seimbang untuk membuat keputusan reka bentuk yang memberikan hasil yang diingini. Mengandungi reka bentuk anda mengikut keperluan untuk mengurangkan ketidakcekapan dan masalah yang berpotensi.

Panduan ini menerangkan cadangan untuk meminimumkan kerumitan dan overhed yang tidak perlu untuk memastikan beban kerja anda mudah dan cekap. Pilih komponen terbaik untuk melaksanakan tugas beban kerja yang diperlukan untuk mengoptimumkan kebolehpercayaan beban kerja anda. Untuk mengurangkan beban pembangunan dan pengurusan anda, manfaatkan kecekapan yang ditawarkan oleh perkhidmatan yang disediakan platform. Reka bentuk ini membantu anda mencipta seni bina beban kerja yang berdaya tahan, boleh diulang, boleh berskala dan boleh diurus.

Definisi

Istilah Takrif
Beban kerja Keupayaan diskret atau tugas pengkomputeran yang boleh anda pisahkan secara logik daripada tugas lain.

Strategi reka bentuk utama

Prinsip utama mereka bentuk untuk kebolehpercayaan ialah memastikan perkara mudah dan cekap. Fokuskan reka bentuk beban kerja anda untuk memenuhi keperluan perniagaan untuk mengurangkan risiko kerumitan yang tidak perlu atau overhed berlebihan. Pertimbangkan cadangan dalam artikel ini untuk membantu anda membuat keputusan tentang reka bentuk anda untuk mencipta beban kerja yang ramping, cekap dan boleh dipercayai. Beban kerja yang berbeza mungkin mempunyai keperluan yang berbeza untuk ketersediaan, kebolehskalaan, konsistensi data dan pemulihan bencana.

Anda mesti mewajarkan setiap keputusan reka bentuk dengan keperluan perniagaan. Prinsip reka bentuk ini mungkin kelihatan jelas, tetapi ia penting untuk reka bentuk beban kerja. Adakah beban kerja anda menyokong berjuta-juta pengguna, atau beberapa ribu? Adakah terdapat letupan trafik yang besar, atau beban kerja yang stabil? Apakah tahap gangguan yang boleh diterima? Keperluan perniagaan mendorong pertimbangan reka bentuk ini.

Pertukaran: Penyelesaian yang kompleks boleh menawarkan lebih banyak ciri dan fleksibiliti, tetapi ia mungkin menjejaskan kebolehpercayaan beban kerja kerana ia memerlukan lebih banyak penyelarasan, komunikasi dan pengurusan komponen. Sebagai alternatif, penyelesaian yang lebih mudah mungkin tidak memenuhi jangkaan pengguna sepenuhnya, atau ia mungkin mempunyai kesan negatif pada kebolehlanjutan apabila beban kerja berkembang.

Latihan reka bentuk kolaboratif

Bekerjasama dengan pihak berkepentingan untuk:

  • Tentukan dan tetapkan tahap kritikal kepada beban kerja anda dan komponennya. Latihan ini akan membantu anda menentukan komponen yang diperlukan dan pendekatan terbaik untuk mencapai tahap daya tahan yang diperlukan. Lihat Takrifkan peringkat aplikasi untuk maklumat lanjut.

  • Tentukan keperluan berfungsi dan tidak berfungsi. Keperluan fungsional menentukan ciri dan tingkah laku sistem. Ia ditentukan oleh pengguna dan ditangkap dalam kes penggunaan. Keperluan tidak berfungsi mentakrifkan atribut prestasi dan kualiti sistem. Pastikan anda memahami keperluan bukan berfungsi seperti ketersediaan, pematuhan, pengekalan/residensi data, prestasi, privasi, masa pemulihan, keselamatan dan kebolehskalaan. Keperluan ini mempengaruhi keputusan reka bentuk dan pilihan teknologi.

    Berikut ialah beberapa contoh keperluan berfungsi dan tidak berfungsi, dalam konteks beban kerja yang mengendalikan laporan perbelanjaan:

    Keperluan fungsi Keperluan tidak berfungsi
    Beban kerja harus membenarkan pengguna log masuk dengan kelayakan mereka dan hanya mengakses data peribadi mereka. Beban kerja hendaklah tersedia sekurang-kurangnya 99.9% daripada masa.
    Beban kerja hendaklah termasuk papan pemuka yang memberikan gambaran keseluruhan laporan perbelanjaan terbuka, diluluskan dan ditolak. Beban kerja hendaklah mematuhi peraturan dan piawaian yang berkaitan untuk perlindungan data dan privasi.
    Beban kerja harus menyokong operasi sandaran dan pemulihan untuk data beban kerja. Beban kerja hendaklah mempunyai masa tindak balas kurang daripada 5 saat untuk kebanyakan permintaan pengguna.
    Beban kerja hendaklah menghantar pemberitahuan kepada pengguna dan pentadbir apabila peristiwa atau ambang tertentu dicetuskan. Beban kerja harus mempunyai tahap keselamatan dan penyulitan yang tinggi untuk data dalam transit dan dalam keadaan rehat.

    Untuk maklumat lanjut, lihat modul latihan bertajuk Bekerja dengan keperluan untuk Microsoft Power Platform dan Dynamics 365.

  • Pecahkan beban kerja kepada komponen. Semasa proses penemuan dan pengumpulan keperluan, beberapa idea penyelesaian harus mula menjadi jelas. Kenal pasti komponen penyelesaian yang mungkin membentuk penyelesaian yang dicadangkan untuk memenuhi keperluan perniagaan anda. Utamakan kesederhanaan, kecekapan dan kebolehpercayaan dalam reka bentuk anda. Tentukan komponen yang anda perlukan untuk menyokong beban kerja anda. Serlahkan di mana keupayaan di luar kotak boleh digunakan dan di mana pembangunan tersuai mungkin diperlukan.

  • Gunakan analisis mod kegagalan untuk mengenal pasti titik kegagalan tunggal dan potensi risiko. Fahami dengan jelas toleransi perniagaan anda terhadap risiko. Untuk maklumat lanjut, lihat Cadangan untuk melaksanakan analisis mod kegagalan.

  • Tentukan sasaran ketersediaan dan pemulihan untuk beban kerja anda untuk memaklumkan keputusan seni bina. Metrik perniagaan termasuk objektif tahap perkhidmatan (SLO), perjanjian peringkat perkhidmatan (SLA), purata masa untuk pulih (MTTR), purata masa antara kegagalan (MTBF), objektif masa pemulihan (RTO) dan objektif titik pemulihan (RPO). Tentukan nilai sasaran untuk metrik ini. Latihan ini mungkin memerlukan kompromi dan persefahaman bersama antara teknologi dan pasukan perniagaan untuk memastikan matlamat setiap pasukan memenuhi objektif perniagaan dan realistik. Untuk maklumat lanjut, lihat Cadangan untuk mentakrifkan sasaran kebolehpercayaan. Power Platform SLA menyediakan komitmen Microsoft untuk masa operasi dan sambungan. Perkhidmatan yang berbeza mempunyai SLA yang berbeza, dan kadangkala SKU dalam perkhidmatan mempunyai SLA yang berbeza. Untuk maklumat lanjut, lihat Perjanjian peringkat perkhidmatan untuk perkhidmatan dalam talian.

Cadangan reka bentuk tambahan

Anda boleh melaksanakan cadangan berikut tanpa penglibatan pihak berkepentingan:

  • Berusaha untuk kesederhanaan dan kejelasan dalam reka bentuk anda. Gunakan tahap abstraksi dan perincian yang sesuai untuk komponen dan perkhidmatan anda. Elakkan kejuruteraan berlebihan atau kekurangan kejuruteraan penyelesaian anda. Contohnya:

    • Jika anda menyelesaikan keperluan automasi proses dengan Power Automate, memecahkan proses besar kepada berbilang aliran awan yang lebih kecil mungkin menjadikannya lebih sukar untuk difahami, diuji dan diselenggara. Sebaliknya, mengekalkan segala-galanya dalam aliran yang besar mungkin mempunyai kesan negatif pada prestasi dan volum panggilan API.

    • Jika anda menyelesaikan keperluan yang dihadapi pengguna dengan Power Apps, apl kanvas monolitik yang besar dengan banyak kawalan mungkin mempunyai kesan negatif terhadap prestasi. Memecahkannya kepada apl tunggal atau halaman tersuai mungkin menyukarkan ujian, tetapi ia boleh memberi kesan positif yang ketara terhadap prestasi.

  • Jangkakan perubahan dari semasa ke semasa, sama ada untuk membetulkan pepijat, melaksanakan ciri atau teknologi baharu atau menjadikan sistem sedia ada lebih berskala dan berdaya tahan.

  • Pindahkan kebimbangan rentas kepada perkhidmatan yang berasingan. Minimumkan keperluan untuk menduplikasi kod merentas fungsi yang berbeza. Lebih suka menggunakan semula perkhidmatan dengan antara muka yang jelas yang boleh digunakan dengan mudah oleh komponen yang berbeza. Contohnya, jika satu set operasi data perlu dilakukan dari tempat yang berbeza, anda boleh mengalihkan fungsi ini ke pemalam kod rendah.

  • Menilai kesesuaian corak dan amalan biasa untuk keperluan anda. Elakkan mengikuti arah aliran atau pengesyoran yang mungkin tidak sesuai untuk konteks atau keperluan anda. Sebagai contoh, melaksanakan komponen kod tersuai mungkin bukan pilihan terbaik untuk setiap aplikasi kerana ia boleh memperkenalkan kerumitan, overhed dan isu kebergantungan.

Membangunkan kod yang mencukupi

Prinsip kesederhanaan, kecekapan dan kebolehpercayaan juga digunakan untuk amalan pembangunan anda. Pertimbangkan cadangan ini:

  • Gunakan keupayaan platform apabila ia memenuhi keperluan perniagaan anda. Contohnya:

    • Gunakan kawalan moden dan bukannya membangunkan komponen kod anda sendiri untuk mencapai standard reka bentuk Fluent 2.
    • Gunakan penyambung asli dan bukannya membangunkan penyambung tersuai untuk mengurangkan kod tersuai.
    • Gunakan jawapan generatif untuk Microsoft Copilot Studio membolehkan ejen anda mencari dan membentangkan maklumat daripada berbilang sumber, dalaman atau luaran, tanpa topik yang dibuat secara manual.

  • Perkenalkan sesi semakan kod khusus sebagai amalan pembangunan.

  • Laksanakan pendekatan untuk mengenal pasti kod mati. Bersikap ragu-ragu terhadap kod yang tidak dilindungi oleh ujian automatik anda.

  • Pertimbangkan set kemahiran pasukan pembangunan anda. Ia mengambil masa untuk mempelajari kemahiran baharu atau menggunakan teknologi baharu.

Pertimbangkan di mana data anda berada

Sebagai sebahagian daripada reka bentuk seni bina anda, anda perlu mempertimbangkan cara menyimpan data anda atau cara mendapatkan semula data anda untuk aktiviti membaca. Data boleh diambil dan disimpan dengan cara yang berbeza:

  • Data baharu: Jika apl anda mencipta data yang belum wujud, seperti apabila proses perniagaan sedia ada dilakukan di atas kertas, kami mengesyorkan agar anda menyimpan data tersebut Microsoft Dataverse.

  • Baca/tulis daripada sistem sedia ada: Jika apl anda perlu mendapatkan semula data daripada pangkalan data atau sistem sedia ada, anda perlu menilai cara terbaik untuk menyambung ke pangkalan data atau sistem: menggunakan penyambung di luar kotak, penyambung tersuai atau jadual maya.

  • Buat salinan data: Dalam situasi di mana data asal tidak boleh diubah suai atau ditulis ganti, anda boleh menyalin data ke stor data lain seperti Dataverse. Strategi ini mengekalkan data sistem asal tidak berubah sambil membenarkan apl anda berfungsi dengannya. Senario ini biasa apabila bekerja dengan data dalam perakaunan dan sistem berkaitan hasil. Anda perlu mempertimbangkan cara data disalin, kekerapan ia dikemas kini dan sama ada penyegerakan dua hala perlu dilakukan.

Power Platform Kemudahan

Untuk nasihat reka bentuk praktikal, rujuk artikel berikut:

Senarai semak kebolehpercayaan

Rujuk set lengkap cadangan.

Senarai semak kebolehpercayaan