امنیت، هویت، استقرار و تاب‌آوری · فصل ۶ — Chaos، Feature Flags، Rollout و ADR · 109
Target DDL → Runtime Projection
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «Target DDL → Runtime Projection». می‌تواند برای «Target DDL → Runtime Projection» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
خلاصهٔ درس
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «Target DDL → Runtime Projection».
می‌تواند برای «Target DDL → Runtime Projection» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
خروجی این درس
می‌تواند برای «Target DDL → Runtime Projection» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
1. مسئله: چیزی که نوشته‌ای با چیزی که اجرا می‌شود یکی نیست
Target DDL یا migration artifact فقط «قصد» را نشان می‌دهد. برای release evidence باید وضعیت مشاهده‌شده‌ی runtime را جدا ببینیم. ممکن است فایل درست باشد اما constraint اجرا نشده، index متفاوت باشد، object به‌دلیل visibility دیده نشود، یا یک object محیطی فقط در runtime وجود داشته باشد. بنابراین این درس هیچ‌وقت سبز بودن migration را معادل اثبات schema واقعی نمی‌گیرد.
2. دو شیء شواهدی مستقل
در DDL Runtime Projection Reconciliation Record v1 دو ستون مستقل داریم: Target Definition و Runtime Observation. اولی از target.sql یا migration artifact می‌آید؛ دومی از projection مشاهده‌شده. نتیجه فقط وقتی بسته می‌شود که source، scope و timestamp هر مشاهده مشخص باشد. inference یا policy choice به‌جای observation نوشته نمی‌شود.
3. Object identity قبل از diff
قبل از مقایسه باید object را با identity پایدار بشناسیم: schema، object type و object name. یک raw text diff ممکن است فقط ترتیب، whitespace، quoting یا قالب خروجی را نشان دهد. هدف ما مقایسه‌ی معنایی table، column، constraint، index و view است؛ نه checksum متن دو dump.
4. Portable projection با information_schema
PostgreSQL، information_schema را به‌عنوان مجموعه‌ای standards-oriented از viewها برای metadata پایگاه‌داده مستند می‌کند [PG-INFO-SCHEMA]. این سطح نقطه شروع خوبی برای observation قابل‌حمل است، اما همه جزئیات PostgreSQL-specific را پوشش نمی‌دهد و visibility هر نقش نیز می‌تواند محدود باشد. نبودن row همیشه «object وجود ندارد» معنا نمی‌دهد.
5. PostgreSQL-specific projection
وقتی جزئیات خاص PostgreSQL لازم است، system catalogها یا information functions می‌توانند تعریف بازسازی‌شده بدهند. برای constraintها باید وجود/type را از metadata جدا کنیم و definition بازسازی‌شده را با برچسب PostgreSQL-specific ثبت کنیم [PG-TABLE-CONSTRAINTS][PG-SYSINFO]. متن بازسازی‌شده همان original DDL نیست.
6. schema-only dump یک projection است، نه حقیقت کامل
pg_dump --schema-only تعریف objectها را بدون داده‌ی table و statistics تولید می‌کند [PG-PGDUMP]. این خروجی برای projection مفید است، ولی application correctness، data integrity، restore success یا runtime traffic را ثابت نمی‌کند. در این درس dump فقط یکی از observation surfaceهاست.
7. Semantic equivalence در برابر textual equality
دو تعریف می‌توانند از نظر متن متفاوت اما از نظر object semantics معادل باشند. مثلاً ترتیب clauseها یا formatting می‌تواند عوض شود بدون اینکه constraint یا index معنا عوض کند. record باید semantic_match را بر اساس object-level facts ثبت کند، نه صرفاً تفاوت رشته‌ها.
8. Expected Difference چیست؟
بعضی تفاوت‌ها از قبل مجاز و قابل توضیح‌اند؛ مثلاً object متعلق به extension یا تفاوت environment-specific که authority آن روشن است. چنین موردی EXPECTED_DIFFERENCE می‌شود، نه drift. شرط مهم: دلیل و authority باید در evidence موجود باشد؛ «به‌نظر طبیعی است» کافی نیست.
9. Drift چیست؟
Drift یعنی target و runtime در object مورد انتظار به‌صورت معنادار واگرا هستند و authority این اختلاف را مجاز نکرده است. حذف foreign key، default متفاوت بدون authority، یا index definition متفاوت می‌تواند drift باشد. Drift باید به repair محدود و rerun متصل شود، نه به تغییرات گسترده‌ی نامرتبط.
10. Unknown را حفظ کن
اگر role مشاهده‌گر object را نمی‌بیند، snapshot ناقص است یا source کافی نیست، نباید ABSENT یا MATCH حدس بزنیم. وضعیت درست UNKNOWN است. این مهم‌ترین مرز این درس است: نبودن evidence با evidence of absence یکی نیست.
11. Negative probe: raw diff گمراه‌کننده
یکی از fixtureها فقط formatting و order dump را عوض می‌کند. raw diff قرمز است اما normalized object comparison معادل می‌ماند. اگر سیستم تو این مورد را drift اعلام کند، diagnostic ضعیف است. این probe ثابت می‌کند comparison باید semantic باشد.
12. Visibility boundary و privilege
در fixture visibility محدود، object هدف در information_schema دیده نمی‌شود اما catalog evidence نیز برای نقش مصنوعی کامل نیست. نتیجه باید UNKNOWN_VISIBILITY بماند. این درس مجوز افزایش privilege یا اتصال به production نمی‌دهد؛ فقط محدودیت observation را ثبت می‌کند.
13. Record را object-by-object بساز
برای هر object این فیلدها را پر کن: Target Definition، Runtime Observation، Observation Source، Visibility Scope، Semantic Match، Expected Difference، Drift، Unknown، Evidence Timestamp و Next Action. release evidence فقط از rowهایی ساخته می‌شود که source و classification روشن دارند.
14. Repair و rerun
اگر drift واقعی است، کوچک‌ترین repair مرتبط را تعریف کن و همان observation surface را دوباره اجرا کن. اگر unknown است، repair نرم‌افزاری نساز؛ evidence gap را هدف بگیر. اگر expected difference است، authority آن را ثبت کن و release را فقط در همان boundary جمع‌بندی کن.
15. Transfer: محیط دوم را از صفر reconcile کن
در fixture دوم schema name، visibility، generated default و index definition تغییر می‌کند. classificationهای محیط اول را کپی نکن. object identity، observation source و semantic relation را دوباره استخراج کن. اگر بتوانی expected، drift و unknown را مستقل دفاع کنی، مهارت منتقل شده است.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
ملاک‌های ارزیابی (rubric)
| Dimension | Sufficient evidence |
|---|---|
| Owned model correctness | Target DDL and observed runtime projection remain distinct evidence objects. |
| Evidence quality | Object identity, observation source, visibility scope, timestamp, and classification are traceable. |
| Negative evidence | Raw textual difference is not mistaken for semantic drift, and incomplete visibility remains UNKNOWN. |
| Classification discipline | Expected difference, drift, and unknown are separated with explicit authority/evidence. |
| Transfer independence | The second environment is reconciled from raw evidence without copying the first classifications. |
Blocking failures: treating target DDL as runtime proof; treating every text diff as drift; converting restricted visibility into absence; inventing authority for expected differences; or claiming schema evidence proves data/application behavior.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
Use only the supplied synthetic fixtures. For each case, construct one row of DDL Runtime Projection Reconciliation Record v1. Keep target definition and runtime observation separate, record observation source and visibility scope, then classify the relationship as semantic match, expected difference, drift, or unknown.
The lab is intentionally offline. Do not connect to any database, request credentials, or infer production state. A raw text difference is not sufficient to call drift, and restricted visibility must remain UNKNOWN until evidence closes it.