Praktik terbaik untuk Workflows

Anda dapat melihat praktik terbaik yang tercantum di sini saat mengatur layanan menggunakan Workflows.

Ini bukan daftar lengkap rekomendasi dan tidak mengajarkan Anda dasar-dasar cara menggunakan Workflows. Dokumen ini mengasumsikan bahwa Anda sudah memiliki pemahaman umum tentang keseluruhan Google Cloud lanskap dan tentang Workflows. Untuk mengetahui informasi selengkapnya, lihat Google Cloud Well-Architected Framework dan Ringkasan alur kerja.

Pilih pola komunikasi yang optimal

Saat mendesain arsitektur microservice untuk men-deploy beberapa layanan, Anda dapat memilih dari pola komunikasi berikut:

  • Komunikasi langsung layanan ke layanan

  • Komunikasi berbasis peristiwa tidak langsung (juga dikenal sebagai koreografi)

  • Konfigurasi, koordinasi, dan pengelolaan otomatis (juga dikenal sebagai orkestrasi)

Pastikan untuk mempertimbangkan manfaat dan kekurangan setiap opsi sebelumnya dan pilih pola yang optimal untuk kasus penggunaan Anda. Misalnya, komunikasi langsung antarlayanan mungkin lebih mudah diterapkan daripada opsi lain, tetapi hal ini akan mengikat layanan Anda secara erat. Sebaliknya, arsitektur berbasis peristiwa memungkinkan Anda mengaitkan layanan secara longgar; namun, pemantauan dan proses debug mungkin lebih rumit. Terakhir, orkestrator pusat seperti Workflows, meskipun kurang fleksibel, memungkinkan Anda mengoordinasikan komunikasi antar-layanan tanpa keterikatan erat komunikasi layanan ke layanan langsung, atau kerumitan peristiwa yang diatur.

Anda juga dapat menggabungkan pola komunikasi. Misalnya, dalam orkestrasi berbasis peristiwa, layanan yang terkait erat dikelola dalam orkestrasi yang dipicu oleh peristiwa. Demikian pula, Anda dapat mendesain sistem yang menghasilkan pesan Pub/Sub ke sistem lain yang diatur.

Tips umum

Setelah Anda memutuskan untuk menggunakan Workflows sebagai orkestrator layanan, perhatikan tips bermanfaat berikut.

Menghindari URL hardcode

Anda dapat mendukung alur kerja yang portabel di beberapa lingkungan dan lebih mudah dikelola dengan menghindari URL yang dikodekan secara permanen. Anda dapat melakukannya dengan cara berikut:

  • Tentukan URL sebagai argumen runtime.

    Hal ini dapat berguna saat alur kerja Anda dipanggil melalui library klien atau API. (Namun, cara ini tidak akan berfungsi jika alur kerja Anda dipicu oleh peristiwa dari Eventarc dan satu-satunya argumen yang dapat diteruskan adalah payload peristiwa.)

    Contoh

    main:
  params: [args]
  steps:
    - init:
        assign:
          - url1: ${args.urls.url1}
          - url2: ${args.urls.url2}

    Saat menjalankan alur kerja, Anda dapat menentukan URL. Misalnya:

    gcloud workflows run multi-env --data='{"urls":{"url1": "URL_ONE", "url2": "URL_TWO"}}'

  • Gunakan variabel lingkungan dan buat alur kerja yang dikonfigurasi secara dinamis, bergantung pada lingkungan tempat alur kerja di-deploy. Atau, buat alur kerja yang dapat digunakan kembali sebagai template dan dikonfigurasi sesuai dengan variabel lingkungan yang dikelola secara terpisah.

  • Gunakan teknik penggantian yang memungkinkan Anda membuat satu file definisi alur kerja, tetapi men-deploy varian menggunakan alat yang menggantikan placeholder dalam alur kerja Anda. Misalnya, Anda dapat menggunakan Cloud Build untuk men-deploy alur kerja dan di file konfigurasi Cloud Build, menambahkan langkah untuk mengganti URL placeholder dalam alur kerja.

    Contoh

    steps:
‐ id: 'replace-urls'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: bash
  args:
    - -c
    - |
      sed -i -e "s~REPLACE_url1~$_URL1~" workflow.yaml
      sed -i -e "s~REPLACE_url2~$_URL2~" workflow.yaml
‐ id: 'deploy-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', 'multi-env-$_ENV', '--source', 'workflow.yaml']

    Kemudian, Anda dapat mengganti nilai variabel pada waktu build. Contoh:

    gcloud builds submit --config cloudbuild.yaml \
    --substitutions=_ENV=staging,_URL1="URL_ONE",_URL2="URL_TWO"

    Untuk mengetahui informasi selengkapnya, lihat Mengirimkan build melalui CLI dan API.

    Atau, Anda dapat menggunakan Terraform untuk menyediakan infrastruktur dan menentukan file konfigurasi yang membuat alur kerja untuk setiap lingkungan menggunakan variabel input.

    Contoh

    variable "project_id" {
  type = string
}

variable "url1" {
  type = string
}

variable "url2" {
  type = string
}

locals {
  env = ["staging", "prod"]
}

# Define and deploy staging and production workflows
resource "google_workflows_workflow" "multi-env-workflows" {
  for_each = toset(local.env)

  name            = "multi-env-${each.key}"
  project         = var.project_id
  region          = "us-central1"
  source_contents = templatefile("${path.module}/workflow.yaml", { url1 : "${var.url1}-${each.key}", url2 : "${var.url2}-${each.key}" })
}

    Saat variabel dideklarasikan dalam modul root konfigurasi Anda, variabel tersebut dapat ditetapkan nilai dengan berbagai cara. Contohnya

    terraform apply -var="project_id=PROJECT_ID" -var="url1=URL_ONE" -var="url2=URL_TWO"

  • Gunakan konektor Secret Manager untuk menyimpan URL dengan aman di Secret Manager dan mengambilnya.

Menggunakan langkah bertingkat

Setiap alur kerja harus memiliki minimal satu langkah. Secara default, Alur Kerja memperlakukan langkah-langkah seolah-olah berada dalam daftar yang berurutan dan mengeksekusinya satu per satu hingga semua langkah selesai dijalankan. Secara logis, beberapa langkah harus dikelompokkan bersama dan Anda dapat menggunakan blok steps untuk menyusun serangkaian langkah. Hal ini memudahkan karena Anda dapat menunjuk ke langkah atomik yang benar untuk memproses serangkaian langkah.

Contoh

main:
    params: [input]
    steps:
    - callWikipedia:
        steps:
        - checkSearchTermInInput:
            switch:
                - condition: ${"searchTerm" in input}
                  assign:
                    - searchTerm: ${input.searchTerm}
                  next: readWikipedia
        - getCurrentDate:
            call: http.get
            args:
                url: https://timeapi.io/api/Time/current/zone?timeZone=Europe/Amsterdam
            result: currentDate
        - setFromCallResult:
            assign:
                - searchTerm: ${currentDate.body.dayOfWeek}
        - readWikipedia:
            call: http.get
            args:
                url: https://en.wikipedia.org/w/api.php
                query:
                    action: opensearch
                    search: ${searchTerm}
            result: wikiResult
    - returnOutput:
            return: ${wikiResult.body[1]}

Ekspresi pembungkus

Semua ekspresi harus dimulai dengan $ dan diapit dalam tanda kurung kurawal:

${EXPRESSION}

Untuk menghindari masalah penguraian YAML, Anda dapat mengapit ekspresi dalam tanda kutip. Misalnya, ekspresi yang berisi titik dua dapat menyebabkan perilaku yang tidak terduga saat titik dua ditafsirkan sebagai penentu peta. Anda dapat mengatasi masalah ini dengan menyertakan ekspresi YAML dalam tanda petik tunggal:

'${"Name: " + myVar}'

Anda juga dapat menggunakan ekspresi yang mencakup beberapa baris. Misalnya, Anda mungkin perlu mengapit kueri SQL dalam tanda petik saat menggunakan konektor BigQuery Workflows.

Contoh

- runQuery:
    call: googleapis.bigquery.v2.jobs.query
    args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        body:
            useLegacySql: false
            useQueryCache: false
            timeoutMs: 30000
            # Find top 100 titles with most views on Wikipedia
            query: ${
                "SELECT TITLE, SUM(views)
                FROM `bigquery-samples.wikipedia_pageviews." + table + "`
                WHERE LENGTH(TITLE) > 10
                GROUP BY TITLE
                ORDER BY SUM(VIEWS) DESC
                LIMIT 100"
                }
    result: queryResult

Untuk definisi alur kerja lengkap, lihat Menjalankan beberapa tugas BigQuery secara paralel.

Menggunakan panggilan deklaratif

Gunakan Workflows untuk memanggil layanan dari alur kerja itu sendiri dan menangani hasilnya, serta untuk mengeksekusi tugas sederhana seperti melakukan panggilan HTTP. Alur kerja dapat memanggil layanan, mengurai respons, dan membuat input untuk layanan terhubung lainnya. Dengan memanggil layanan, Anda dapat menghindari komplikasi pemanggilan tambahan, dependensi tambahan, dan layanan yang memanggil layanan. Pertimbangkan untuk mengganti layanan yang bebas dari logika bisnis dengan panggilan API deklaratif dan gunakan Workflows untuk menyederhanakan kompleksitas.

Namun, Anda harus membuat layanan untuk melakukan pekerjaan yang terlalu rumit untuk Workflows; misalnya, menerapkan logika bisnis yang dapat digunakan kembali, komputasi yang rumit, atau transformasi yang tidak didukung oleh ekspresi Workflows dan library standarnya. Kasus yang rumit biasanya lebih mudah diimplementasikan dalam kode, daripada menggunakan YAML atau JSON dan sintaksis Workflows.

Simpan hanya yang Anda butuhkan

Jaga agar penggunaan memori tetap terkendali agar Anda tidak mengalami batas resource atau error yang menunjukkan hal ini seperti ResourceLimitError, MemoryLimitExceededError, atau ResultSizeLimitExceededError.

Pilih-pilih apa yang Anda simpan dalam variabel, memfilter dan menyimpan hanya yang Anda butuhkan. Jika layanan menampilkan payload yang terlalu besar, gunakan fungsi terpisah untuk melakukan panggilan bagi Anda dan hanya menampilkan yang diperlukan.

Anda dapat mengosongkan memori dengan menghapus variabel. Misalnya, Anda mungkin ingin membebaskan memori yang diperlukan untuk langkah-langkah berikutnya. Atau, Anda mungkin memiliki panggilan dengan hasil yang tidak Anda inginkan, dan Anda dapat menghapus hasil tersebut sepenuhnya.

Anda dapat menghapus variabel dengan menetapkan null. Di YAML, Anda juga dapat menetapkan nilai kosong atau ~ ke variabel. Hal ini mengidentifikasi memori yang dapat diklaim kembali dengan aman.

Contoh

  - step:
      assign:
        - bigVar:

Menggunakan sub-alur kerja dan alur kerja eksternal

Anda dapat menggunakan sub-alur kerja untuk menentukan bagian logika atau serangkaian langkah yang ingin Anda panggil beberapa kali, sehingga menyederhanakan definisi alur kerja. Sub-alur kerja mirip dengan fungsi atau rutin dalam bahasa pemrograman. Fungsi ini dapat menerima parameter dan menampilkan nilai, sehingga Anda dapat membuat alur kerja yang lebih kompleks dengan berbagai aplikasi yang lebih luas.

Perhatikan bahwa sub-alur kerja bersifat lokal untuk definisi alur kerja Anda dan tidak dapat digunakan kembali dalam alur kerja lain. Namun, Anda dapat memanggil alur kerja dari alur kerja lain. Konektor Alur kerja dapat membantu Anda melakukan hal ini. Untuk mengetahui informasi selengkapnya, lihat ringkasan konektor untuk Workflow Executions API dan Workflows API.

Menggunakan konektor Workflows

Workflows menyediakan sejumlah konektor yang mempermudah akses ke produk Google Cloud lain dalam alur kerja. Konektor menyederhanakan panggilan layanan karena menangani pemformatan permintaan untuk Anda, menyediakan metode dan argumen sehingga Anda tidak perlu mengetahui detail Google Cloud API. Konektor juga memiliki perilaku bawaan untuk menangani percobaan ulang dan operasi yang berjalan lama sehingga Anda tidak perlu melakukan iterasi dan menunggu panggilan selesai; konektor akan menanganinya untuk Anda.

Jika Anda perlu memanggil Google Cloud API, periksa terlebih dahulu apakah ada konektor Workflows untuk API tersebut. Selain itu, jika Anda tidak melihat konektor untuk produk Google Cloud , Anda dapat memintanya.

Pelajari cara menggunakan konektor dan, untuk referensi mendetail tentang konektor yang tersedia, lihat Referensi konektor.

Menjalankan langkah-langkah alur kerja secara paralel

Meskipun Workflows dapat menjalankan langkah-langkah secara berurutan, Anda juga dapat menjalankan langkah-langkah independen secara paralel. Dalam beberapa kasus, hal ini dapat mempercepat eksekusi alur kerja Anda secara signifikan. Untuk mengetahui informasi selengkapnya, lihat Menjalankan langkah-langkah alur kerja secara paralel.

Menerapkan percobaan ulang dan pola saga

Rancang alur kerja yang tangguh dan dapat menangani kegagalan layanan sementara dan permanen. Error untuk Workflows dapat muncul, misalnya, karena permintaan HTTP, fungsi, konektor yang gagal, atau dihasilkan oleh kode alur kerja Anda sendiri. Tambahkan penanganan error dan percobaan ulang agar kegagalan di satu langkah tidak menyebabkan seluruh alur kerja gagal.

Beberapa transaksi bisnis mencakup beberapa layanan sehingga Anda memerlukan mekanisme untuk menerapkan transaksi yang mencakup layanan. Pola desain saga adalah cara untuk mengelola konsistensi data di seluruh microservice dalam skenario transaksi terdistribusi. Saga adalah urutan transaksi yang memublikasikan peristiwa untuk setiap transaksi dan yang memicu transaksi berikutnya. Jika transaksi gagal, saga akan menjalankan transaksi kompensasi yang menangkal kegagalan sebelumnya dalam urutan. Coba tutorial Retries and Saga Pattern in Workflows di GitHub.

Menggunakan callback untuk menunggu

Callback memungkinkan eksekusi alur kerja menunggu layanan lain membuat permintaan ke endpoint callback; permintaan tersebut melanjutkan eksekusi alur kerja.

Dengan callback, Anda dapat memberi sinyal ke alur kerja bahwa peristiwa tertentu telah terjadi, dan menunggu peristiwa tersebut tanpa polling. Misalnya, Anda dapat membuat alur kerja yang memberi tahu Anda saat produk tersedia kembali atau saat item telah dikirim; atau yang menunggu untuk memungkinkan interaksi manusia seperti meninjau pesanan atau memvalidasi terjemahan. Anda juga dapat menunggu peristiwa menggunakan callback dan pemicu Eventarc.

Mengorkestrasi tugas yang berjalan lama

Jika perlu menjalankan workload pemrosesan batch yang berjalan lama, Anda dapat menggunakan Batch atau tugas Cloud Run, dan Anda dapat menggunakan Workflows untuk mengelola layanan. Dengan begitu, Anda dapat menggabungkan keunggulan dan menyediakan serta mengatur seluruh proses secara efisien.

Batch adalah layanan terkelola sepenuhnya yang memungkinkan Anda menjadwalkan, memasukkan dalam antrean, dan menjalankan workload batch pada instance virtual machine (VM) Compute Engine. Anda dapat menggunakan konektor Workflows untuk Batch guna menjadwalkan dan menjalankan tugas Batch. Untuk mengetahui detailnya, coba tutorialnya.

Tugas Cloud Run digunakan untuk menjalankan kode yang melakukan pekerjaan (tugas) dan berhenti ketika pekerjaan tersebut selesai. Workflows memungkinkan Anda menjalankan tugas Cloud Run sebagai bagian dari alur kerja untuk melakukan pemrosesan data yang lebih kompleks atau mengorkestrasi sistem tugas yang ada. Coba tutorial yang mendemonstrasikan cara menggunakan Workflows untuk menjalankan tugas Cloud Run.

Memasukkan tugas yang berjalan lama ke dalam container

Anda dapat mengotomatiskan eksekusi container yang berjalan lama menggunakan Workflows dan Compute Engine. Misalnya, Anda dapat membuat tugas yang berjalan lama dalam container agar dapat berjalan di mana saja, lalu menjalankan container di VM Compute Engine selama durasi maksimum eksekusi alur kerja (satu tahun).

Dengan Workflows, Anda dapat mengotomatiskan pembuatan VM, menjalankan container di VM, dan menghapus VM. Hal ini memungkinkan Anda menggunakan server dan menjalankan container, tetapi mengabstraksi kompleksitas pengelolaan keduanya, dan dapat membantu jika Anda mengalami batasan waktu saat menggunakan layanan seperti fungsi Cloud Run atau Cloud Run. Coba tutorial Long running containers with Workflows and Compute Engine di GitHub.

Menjalankan alat command line dari Workflows

Cloud Build adalah layanan yang mengeksekusi build Anda di Google Cloud sebagai serangkaian langkah build, dengan setiap langkah build dijalankan dalam container Docker. Eksekusi langkah build serupa dengan eksekusi perintah dalam skrip.

Google Cloud CLI mencakup alat command line gcloud, bq, dan kubectl, tetapi tidak ada cara langsung untuk menjalankan perintah gcloud CLI dari Workflows. Namun, Cloud Build menyediakan image container yang menyertakan gcloud CLI. Anda dapat menjalankan perintah gcloud CLI di container tersebut dari langkah Cloud Build, dan Anda dapat membuat langkah tersebut di Workflows menggunakan konektor Cloud Build.

Contoh

Menjalankan gcloud dalam alur kerja:

# This example shows how to execute gcloud commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: gcloud
      args:
          args: "workflows list"
      result: result
  - return_result:
      return: ${result}

gcloud:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/google.com/cloudsdktool/cloud-sdk
            entrypoint: /bin/bash
            args: ${["-c", "gcloud " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Run kubectl in a workflow:

# This example shows how to execute kubectl commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: kubectl
      args:
          args: "--help"
      result: result
  - return_result:
      return: ${result}

kubectl:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/cloud-builders/kubectl
            entrypoint: /bin/bash
            args: ${["-c", "kubectl " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Menggunakan Terraform untuk membuat alur kerja

Terraform adalah alat infrastruktur sebagai kode yang memungkinkan Anda membuat, mengubah, dan meningkatkan kualitas infrastruktur cloud secara tepat menggunakan kode.

Anda dapat menentukan dan men-deploy alur kerja menggunakan resource google_workflows_workflow Terraform. Untuk mengetahui informasi selengkapnya, lihat Membuat alur kerja menggunakan Terraform.

Untuk membantu Anda mengelola dan memelihara alur kerja yang besar, Anda dapat membuat alur kerja dalam file YAML terpisah dan mengimpor file tersebut ke Terraform menggunakan fungsi templatefile yang membaca file di jalur tertentu dan merender kontennya sebagai template.

Contoh

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow YAML file
    source_contents = templatefile("${path.module}/workflow.yaml",{})
  }

Demikian pula, jika Anda memiliki alur kerja utama yang memanggil beberapa sub-alur kerja, Anda dapat menentukan alur kerja utama dan sub-alur kerja dalam file terpisah, dan menggunakan fungsi templatefile untuk mengimpornya.

Contoh

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow and subworkflow YAML files
    source_contents = join("", [
      templatefile(
        "${path.module}/workflow.yaml",{}
      ),

      templatefile(
        "${path.module}/subworkflow.yaml",{}
      )])
  }

Perhatikan bahwa jika Anda merujuk ke nomor baris saat men-debug alur kerja, semua file YAML yang diimpor melalui file konfigurasi Terraform akan digabungkan dan di-deploy sebagai satu alur kerja.

Men-deploy alur kerja dari repositori Git

Cloud Build menggunakan pemicu build untuk mengaktifkan otomatisasi CI/CD. Anda dapat mengonfigurasi pemicu untuk memproses peristiwa masuk, seperti saat commit baru di-push ke repositori atau saat permintaan pull dimulai, lalu mengeksekusi build secara otomatis saat peristiwa baru masuk.

Anda dapat menggunakan pemicu Cloud Build untuk memulai build dan men-deploy alur kerja dari repositori Git secara otomatis. Anda dapat mengonfigurasi pemicu untuk men-deploy alur kerja Anda berdasarkan setiap perubahan pada repositori sumber, atau men-deploy alur kerja hanya jika perubahan sesuai dengan kriteria tertentu.

Pendekatan ini dapat membantu Anda mengelola siklus proses deployment. Misalnya, Anda dapat men-deploy perubahan ke alur kerja di lingkungan staging, menjalankan pengujian terhadap lingkungan tersebut, lalu meluncurkan perubahan ini secara bertahap ke lingkungan produksi. Untuk mengetahui informasi selengkapnya, lihat Men-deploy alur kerja dari repositori Git menggunakan Cloud Build.

Mengoptimalkan penggunaan

Biaya untuk menjalankan alur kerja sangat minim. Namun, untuk penggunaan volume tinggi, terapkan panduan berikut untuk mengoptimalkan penggunaan dan mengurangi biaya:

  • Daripada menggunakan domain kustom, pastikan semua panggilan ke layanan Google Cloud menggunakan *.appspot.com, *.cloud.goog, *.cloudfunctions.net, atau *.run.app sehingga Anda ditagih untuk langkah internal, bukan eksternal.

  • Terapkan kebijakan percobaan ulang kustom yang menyeimbangkan kebutuhan latensi dan keandalan Anda dengan biaya. Percobaan ulang yang lebih sering akan menurunkan latensi dan meningkatkan keandalan, tetapi juga dapat meningkatkan biaya.

  • Saat menggunakan konektor yang menunggu operasi yang berjalan lama, tetapkan kebijakan polling kustom yang mengoptimalkan latensi untuk biaya. Misalnya, jika Anda memperkirakan operasi akan memakan waktu lebih dari satu jam, Anda mungkin menginginkan kebijakan yang awalnya melakukan polling setelah satu menit jika terjadi kegagalan langsung, lalu setiap 15 menit setelah itu.

  • Gabungkan penugasan menjadi satu langkah.

  • Hindari penggunaan langkah sys.log yang berlebihan. Sebaiknya gunakan pencatatan panggilan.

Ringkasan praktik terbaik

Tabel berikut merangkum tips umum dan praktik terbaik yang direkomendasikan dalam dokumen ini.

Tips umum
Praktik terbaik

Langkah berikutnya