انتشار قناری از خدمات پرداخت

1) چرا به مستندات معامله نیاز دارم ؟

• تبدیل دانش شفاهی به روش های قابل تکرار
• تعریف مرزهای مسئولیت و نقاط تشدید
• به عنوان یک منبع شواهد برای انطباق و ایمنی عمل می کند ؛
• سرعت بخشیدن به کشتی و کاهش خطرات «گردن باریک».

2) طبقه بندی سند (چه چیزی)

سیاست: اهداف و چارچوب («چه و چرا»). مثال: سیاست مدیریت حوادث.
استاندارد: حداقل الزامات اجباری («چقدر»). مثال: تاریخ تجدید گواهی TLS.
SOP/Procedure: مراحل متوالی («به عنوان»). مثال: رها کردن با رول قناری.
Runbook: دستورالعمل های گام به گام برای رویدادهای معمولی (هشدارها/عملیات). مثال: «API 5xx رشد کرده است - الگوریتم اقدامات».
Playbook: مجموعه ای از راه حل های سناریو با گزینه ها و چنگال ها. مثال: «مشکلات با یک ارائه دهنده پرداخت».
KB (پایگاه دانش): پاسخ، سوالات متداول، کمک ابزار.
چک لیست - یک لیست کوتاه از موارد مورد نیاز قبل از اقدامات.
ضبط/شواهد: ورود به سیستم از مراحل تکمیل شده، تصاویر/سیاهههای مربوط/امضا.

قانون: سیاست/استاندارد به آرامی در حال تغییر است، SOP/Runbook/Playbook - اغلب تکامل یافته و در Git زندگی می کنند.

3) اصول مستندات خوب

منبع واحد حقیقت (SSOT) اسناد تکراری نیستند ؛ اسپري کردن منسوخ شده.
اسناد به عنوان کد ما در Git ذخیره می کنیم، بررسی کد را انجام می دهیم، نسخه ها و پخش ها قابل مشاهده هستند.
اول قابل اجرا در ابتدا - یک کارت کوتاه: چه زمانی برای شروع، چه کسی مالک است، چه کاری باید انجام دهد، معیارهای تکمیل.
اتمی بودن و آدرس پذیری یک سند - یک کار/فرآیند.

قابلیت به روز رسانی پاک کردن مالک و به روز رسانی SLA (به عنوان مثال سه ماهه)

قابل مشاهده بودن لینک به داشبورد/هشدار/متریک تعبیه شده است.
امنیت توسط طراحی. طبقه بندی حساسیت، ماسک مخفی، کنترل دسترسی.

4) چرخه عمر سند (حکومت)

1. شروع: درخواست/بلیط → نوع سند → مالک.
2. پیش نویس: قالب، حداقل نمونه ها، مراجع به استانداردها و SLO.
3. مرور: فنی (SRE/پلت فرم/ایمنی)، رویه ای (مدیر فرآیند).
4. انتشار: در شاخه اصلی، علامت گذاری نسخه/تاریخ، اختصاص وضعیت (فعال/تجربی/منسوخ).
5. آموزش/ارتباطات: اعلام تغییرات، آموزش کوتاه/نسخه ی نمایشی.
6. گذشته نگر: بر اساس نتایج حاصل از حوادث/تمرینات، ایجاد تغییرات.
7. ممیزی و آرشیو: ردیابی غیر قابل تغییر (چه کسی/زمانی که تغییر)، نسخه های قدیمی در آرشیو.

5) ساختار SOP/Runbook (حداقل)

1. کارت: نام، شناسه، نسخه/تاریخ، مالک، نقش مسئول، سیاست های مرتبط/استانداردها.
2. زمان درخواست: شرایط شروع (پنجره هشدار/رویداد/کار).
3. آماده سازی: حقوق/ابزار/داده ها، ارزیابی ریسک، ارتباطات.
4. مراحل: شماره گذاری شده، با دستورات/تصاویر/نتایج مورد انتظار.
5. معیارهای موفقیت/بازگشت: آستانه SLI/SLO روشن است.
6. تشدید: چه کسی، چه زمانی و چگونه (کانال، تلفن، ارائه دهنده).
7. امنیت/انطباق: داده های حساس، ممنوعیت ها، سوابق اقدامات.
8. پس از اقدامات: بسته شدن بلیط، به روز رسانی وضعیت، جمع آوری شواهد.

9. تاریخچه تغییرات (Changelog)

6) سبک و قوانین طراحی

واضح و کوتاه: 1 مرحله - 1 عمل - 1 نتیجه.
ضروری: «اجرا»...، «بررسی»...، «بازگشت»...
تصاویر/دستورات: در کنار مرحله ؛ دستورات - بلوک های کپی شده ؛ خروجی مورد انتظار را یادداشت کنید.
تنوع: شاخه ها «اگر A → مرحله X، اگر B → مرحله Y».
کوهورت: در صورت لزوم - مناطق/ارائه دهندگان/مستاجران را مشخص کنید.
محلی سازی: اسناد کلیدی - حداقل 2 زبان ؛ وضعیت ترجمه ها را مشخص کنید.
برچسب ها و جستجو: سرویس، جزء، ارائه دهنده، نوع حادثه، SLO، نسخه.

7) اسناد به عنوان کد و ابزار

ذخیره سازی: Git (main/feat/bugfix)، بررسی PR، چک های مورد نیاز.
فرمت: نشانه گذاری/AsciiDoc ؛ نمودار در طرح PlantUML/پری دریایی JSON/YAML.
انتشار: سایت استاتیک (Docusaurus/MkDocs) + جستجو.
تأیید: CI-lint، تست پیوند، املا، اعتبار سنج بلوک کد.
ادغام: دستورات ChatOps «/runbook open X »، نمایش آخرین نسخه در هشدارها.
لینک ها: کاتالوگ CMDB/خدمات ↔ مستندات ↔ داشبورد.

8) کنترل دسترسی و طبقه بندی

Классы: عمومی/داخلی/محرمانه/محدود.
جداسازی: دستورالعمل های عمومی (وضعیت های عمومی) در مقابل خصوصی (کلید ها، دستورات، نمودارهای شبکه).
اسرار: ممنوع در متن; استفاده از ذخیره سازی مخفی و متغیرهایی.
حسابرسی - خواندن/تغییر ورود به سیستم برای SOP های حساس.

9) ارتباط با حوادث و انتشار

در هر هشدار - یک لینک به runbook مربوطه.
در هر حادثه، اشاره به SOP استفاده شده و چک کردن علائم.
پس از RCA - اسناد را به عنوان عمل CAPA به روز کنید.
قبل از انتشار - چک لیست: آمادگی برگشت، پرچم تخریب، اطلاعات تماس ارائه دهنده.

10) حداقل مجموعه مورد نیاز (MVP Dock Pack)

مدیریت حوادث و سیاست تشدید (سطح SEV/P، زمان بندی).
نظارت بر استاندارد و سیاست هشدار (میزان سوختگی، حد نصاب).
SOP: release/rollback (canary/blue-green)، مهاجرت پایگاه داده (expand/contract).
Runbook: «نرخ خطای بالا»، «رشد P99»، «افت موفقیت پرداخت»، «مشکل TLS/DNS».
کتابچه راهنمای ارائه دهندگان خارجی (پرداخت/KYC/CDN): مخاطبین، محدودیت ها، پوشه ها.

سیاست مدیریت دسترسی و محرمانه

RCA و قالب های پس از مرگ.
جدول مالکیت خدمات (RACI) و نقشه داشبورد.

11) معیارهای کیفیت مستندات (سند SLO)

پوشش:٪ از مسیرهای بحرانی با SOP/Runbook.
تازگی: سهم اسناد جدیدتر از N روز (به عنوان مثال، 90) است.
قابلیت استفاده:٪ از حوادث بسته با توجه به runbook بدون تشدید.
قابلیت یافتن: زمان جستجوی متوسط برای سند مورد نظر (توسط نظرسنجی/سیاهههای مربوط).
نرخ نقص: تعداد نظرات در هر بررسی/اسناد 100.
Adoption: درصد هشدارها با مرجع runbook صحیح.
میزان شواهد انطباق:٪ از وظایف با شواهد پیوست شده.

12) چک لیست

چک لیست ایجاد SOP

• مالک و مخاطب هدف تعریف شده است.
• شرایط شروع و معیارهای توقف وجود دارد.
• مراحل قابل تکرار هستند، توسط مهندس دیگری بررسی می شود.
• ساخته شده در لینک به داشبورد/هشدار/ابزار.

• عقب نشینی و تشدید را توصیف می کند.
• اضافه شده «پس از عمل» چک لیست.
• نسخه، تاریخ، تغییرات.

• سند مربوط به طبقه بندی (سیاست ها و مراحل را مخلوط نمی کند).
• زبان ساده، ضروری، بدون ابهام است.
• تیم های آزمایش شده در «اجرا خشک «/مرحله.
• خطرات و نقاط کنترل نشان داده شده است.
• داخلی/محدود درست است.
• خطوط/اعتبار سنج در CI گذشت.

[بدون هیچ رازی ؛ يه تعميرکار هست و يک اتصال به گاوصندوق.

چک لیست بررسی


13) محلی سازی، نسخه و در دسترس بودن

نسخه: "سرگرد. جزئی است. PATCH، جایی که MAJOR سازگاری فرآیند را می شکند.
زبان ها: علامت گذاری به عنوان «منبع» زبان و وضعیت ترجمه (به روز/نیاز به بررسی).
فاکتور فرم: صفحه نمایش تلفن همراه/شب برای تماس، کارت های IC چاپ شده.

14) اتوماسیون داک (از عمل)

ایجاد چارچوب SOP از قالب CLI ('doc sop جدید --service = پرداخت').
درج خودکار پیوندها به جدیدترین داشبوردها توسط برچسبهای سرویس.
ربات های یادآوری اسناد عقب افتاده (SLA طراوت).
صادرات بسته شواهد برای دوره (PDF/ZIP) برای حسابرسی.
تیکت های حادثه را با نسخه اسناد مورد استفاده در راه حل مرتبط کنید.

15) ایمنی و انطباق

بخش های اجباری «خطرات» و «اقدامات کنترل».
ذخیره شواهد در یک آرشیو بدون تغییر با امضا/هش.
پایبندی به مقررات (به عنوان مثال دوره های اطلاع رسانی/نگهداری)، صاحبان انطباق صریح.

16) ضد الگوهای

«ویکی پیچ و خم» بدون صاحبان و تاریخ به روز رسانی.
سیاستمداران با تیم ها مخلوط می شوند - هیچ کس نمی داند چه باید بکند.
اسناد بدون زمینه (بدون SLO، داشبورد، افزایش).
تصاویر با اسرار و یا «اینجا کلیک کنید» دستورالعمل بدون جایگزین CLI.
«یک گورو می داند که چگونه» - دانش قبیله ای بدون تثبیت.
PDF های بایگانی شده به عنوان تنها نسخه ویرایش نمی شوند، جستجو نمی شوند.

17) قالب (قطعات)

کلاه SOP (به عنوان مثال)

شناسه SOP: OPS-REL-001

18) قرار دادن در کار روزانه

doc-circles هفتگی: تجزیه و تحلیل اسناد 1-2، به روز رسانی، تبادل تجربه.
روزهای بازی: بررسی واقعیت SOP/Runbook در شبیه سازی ها.
Onboarding: مسیر مبتدی از طریق مجموعه ای از اسناد اجباری + آزمون های کوتاه.
بدهی بارانداز: عقب ماندگی پیشرفت با اولویت بندی (تاثیر × تلاش).

19) خط پایین

مستندات معامله یک آرشیو نیست، بلکه یک ابزار کار است. هنگامی که آن را به عنوان کد مدیریت می شود، دارای صاحبان، معیارهای طراوت است و در حوادث، انتشار و آموزش تعبیه شده است، سازمان قابل پیش بینی می شود: اشتباهات کمتر، واکنش سریع تر، مسئولیت قابل درک و آمادگی برای حسابرسی. به طور خلاصه بنویسید، به طور منظم به روز رسانی کنید، روال را خودکار کنید - و مستندات شروع به صرفه جویی در وقت و پول می کنند.