Релизийн бэлэн байдал

Iroha хэрэглээ эсвэл сүлжээний өөрчлөлтийг нэвтрүүлэхээс өмнө холбогдох эрсдэлийг илрүүлж чадах хамгийн жижиг орчинд ажиллагааг нь баталгаажуул. Дараа нь хамтарсан тестнет болон үйлдвэрлэлийн шалгууруудыг зориудын дарааллаар давна.

Орон нутгийн сүлжээний хаалга

• Iroha урсгалын ижил төстэй, хамгийн ойрын практикийн баталгаажуулагчдын тоотой нэг удаагийн орон нутгийн сүлжээг эхлүүлэх.
• Транзакцын бүтээн байгуулагч, хайлтын шинжилгээ, татгалзсан хэрэгслийн хангамж, конфигурацийн ачааллын нэгжийн туршилтыг явуулаарай.
• Хэрэглээний дараа ашиглах ижил SDK эсвэл CLI хэлбэрээр хамгийн жижиг амжилттай унших, бичүүлэх замыг туршиж үзээрэй.
• Экспериментийн артефакт дээр хүлээгдсэн гүйлгээний хэшүүд, статусууд, үйл явдлууд, байдлын тоог аваарай.

Гэрээгүүлэх Iroha 3 болон SDK Сургалтын хувилбар.

Хамтарсан тест торгийн хаалга

• Endpoint-ийн ажиллагаа, шимтгэл, дансны санхүүжилт, latency болон ажиллагааны сургуулилтад Taira эсвэл өөр хамтарсан тестнет ашиглана.
• Ердийн туршилтууд сүлжээний бэлэн байдлаас хамаарахгүй, тестнетийн хөрөнгө зарцуулахгүй байлгахын тулд шууд тестнетэд бичих үйлдлийг зөвхөн илэрхий сонголтоор (opt-in) ажиллуулна.
• Шууд тестийн гүйлгээ бүрийг илгээхээс өмнө signer-ийн санхүүжилт, шимтгэлийн хөрөнгийн metadata, authority-ийн зөвшөөрөл болон хүлээгдэж буй төлөвийг шалгана.
• Эцсийн төлөв иртэл хүлээгээд, үүссэн төлөвийг зөвхөн унших query-ээр баталгаажуулна.

Та үзээрэй. Үргэлжүүлээрэй SORA 3: Taira болон Minamoto.

Төв сүлжээ эсвэл үйлдвэрлэлийн хаалга

• Үйлдвэрлэлийн гарын үсэг зурагчид, санхүүжилт, домэйнууд болон тохиргооны замуудыг тусад нь ашиглана. Тестнетийн түлхүүр болон faucet-ийн таамаглалыг үйлдвэрлэлд бүү шилжүүл.
• Шаардлагатай cross-SDK хувилбаруудыг Нийцтэй байдлын матриц-аар баталгаажуулна. Үүнээс тусад нь байршуулалт ашиглах яг тэр node release, тохиргоотой ижил орчинд CLI, peer binary болон SDK-уудыг тогтоон туршина.
• Релизийн цонхоос өмнө зөвшөөрөл, шимтгэлийн sponsorship, rate limit, monitoring, backup-ийн төлөв болон rollback шалгуурыг хянана.
• Их нөлөөтэй бичих үйлдэлд бичгээр баталгаажуулсан transaction эсвэл migration төлөвлөгөө шаардана.

Буцаалт ба сэргээх ажиллагаа

• Ямар өөрчлөлтийг code deploy-оор буцааж болох, аль нь on-chain transaction шаардах, алийг нь шууд буцаах боломжгүйг тодорхойлно.
• On-chain өгөгдлийн өөрчлөлтөд анхны үйлдвэрлэлийн бичилтээс өмнө нөхөн transaction эсвэл migration script бэлтгэнэ.
• Сүлжээний өөрчлөлтийн үед өмнөх binary, config bundle, гарын үсэгтэй genesis болон ажиллагааны runbook-ийг релизийн турш бэлэн байлгана.
• Rejection rate, queue growth, latency эсвэл peer health зэрэг бодит дохионд үндэслэн rollout-ийг зогсоох шийдвэрийн цэг тогтооно.

Эцсийн шалгалтын жагсаалт

• Тохиргоо нь тухайн орчинд зориулагдсан бөгөөд зөвхөн тестэд хэрэглэх нууц агуулаагүй.
• Transaction retry нь idempotent эсвэл илэрхий хязгаартай.
• Хэрэглээ rejection, expiry, timeout болон endpoint availability-ийн алдааг хооронд нь ялгаж чадна.
• Monitoring нь throughput, latency, queue depth, rejection, view change болон холбогдох бизнесийн үйл явдлыг хамарна.
• Операторуудад хүлээгдэж буй алдааны горим бүрийн runbook байна.
• Аюулгүй байдлын хяналт нь key custody, зөвшөөрөл, сүлжээний exposure болон automation authority-г хамарсан.