امنیت، هویت، استقرار و تاب‌آوری · فصل ۴ — Linux/Windows، Container، DNS، CDN و Storage · 95
Windows Service Fundamentals
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «Windows Service Fundamentals». می‌تواند برای «Windows Service Fundamentals» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
خلاصهٔ درس
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «Windows Service Fundamentals».
می‌تواند برای «Windows Service Fundamentals» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
خروجی این درس
می‌تواند برای «Windows Service Fundamentals» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
پیش‌نیازها
1. مسئله: وجود یک process در حال اجرا evidence کافی نیست
ممکن است یک executable در پس‌زمینه اجرا باشد، اما Windows Service identity، تنظیم startup، account، lifecycle state، control handling یا recovery آن اشتباه فهمیده شده باشد. اگر همه این لایه‌ها در عبارت «process در حال اجراست» خلاصه شوند، عملیات قابل‌اتکا نخواهد بود.
خروجی این درس Windows Service Lifecycle Evidence Record v1 است. این رکورد هویت Service Control Manager یا SCM، binary/config، Service Account، Start Type، dependencyها، status transitionها، controlها، failure actionها، readiness برنامه، recovery evidence و unknownها را جدا نگه می‌دارد.
2. SCM هماهنگ‌کننده lifecycle سرویس است
در Windows، Service Control Manager پایگاه سرویس‌های نصب‌شده را نگه می‌دارد، سرویس‌ها را start می‌کند، status آن‌ها را نگه می‌دارد و control requestها را منتقل می‌کند. بنابراین SCM-visible state یک لایه مستقل از evidence است.
هر process طولانی‌مدت به‌صورت خودکار Windows Service نیست. رکورد باید از Service Name و configuration قابل مشاهده برای SCM شروع شود، نه فقط از فهرست processها.
3. Registration و configuration بیانگر intent هستند، نه اثبات runtime
رکورد سرویس می‌تواند Binary Path، startup behavior، dependencyها و account را مشخص کند. این مقادیر configuration مورد انتظار را توضیح می‌دهند؛ اما ثابت نمی‌کنند process فعلی سالم، ready یا در دسترسی به dependencyها موفق است.
Configuration evidence و runtime observation را در فیلدهای جدا نگه دار. اگر با هم ناسازگارند، قبل از diagnosis هر دو observation را حفظ کن.
4. Start Type مشخص می‌کند SCM چه زمانی سرویس را start می‌کند
الگوهای Automatic، delayed/triggered و demand-start lifecycle intent متفاوتی دارند. Automatic بودن سرویس تضمین نمی‌کند همه منابع بیرونی دقیقاً هنگام شروع کار برنامه آماده باشند.
در Lab، startup mode به‌صورت مستقیم در fixture وجود دارد. آن را از موفق بودن یک اجرا یا صرفاً وجود process حدس نزن.
5. Service Account یک مرز هویتی ایجاد می‌کند
سرویس تحت یک account یا service identity مشخص اجرا می‌شود. این identity روی دسترسی به file، registry object، network resource و سایر منابع محافظت‌شده اثر دارد.
در access failure ابتدا evidence مربوط به مرز identity/resource را بررسی کن. افزایش گسترده privilege راه‌حل پیش‌فرض نیست؛ نتیجه باید تا حد ممکن محدود و قابل اثبات باشد.
6. Status reporting یک protocol است، نه oracle سلامت برنامه
سرویس lifecycle status خود را به SCM گزارش می‌کند. حالت‌هایی مانند start-pending، running، stop-pending و stopped درباره service-control lifecycle هستند.
این stateها readiness مخصوص برنامه را خودکار نشان نمی‌دهند. SERVICE_RUNNING می‌تواند هم‌زمان با readiness marker ناموفق یا dependency application-level ناسالم دیده شود. پس SCM status و application-health evidence باید جدا بمانند.
7. ServiceMain و control handler رابط سرویس را شکل می‌دهند
یک Windows Service به SCM متصل می‌شود، control handler ثبت می‌کند، initialization را انجام می‌دهد و هنگام تغییر state، status را گزارش می‌کند. درخواست‌هایی مثل stop از همین service-control interface عبور می‌کنند.
سؤال عملی فقط این نیست که «command اجرا شد یا نه». باید دید control مورد انتظار پذیرفته شد و status transition مرتبط مستقیماً مشاهده شد یا نه.
8. Control و status transition باید با هم تطبیق داده شوند
ارسال control request یک observation است و state transition حاصل از آن observation دیگری است. برای مثال، ارسال stop به‌تنهایی ثابت نمی‌کند سرویس clean به SERVICE_STOPPED رسیده است.
Control Sent، status قبل و بعد و Exit/Error Evidence را جدا ثبت کن. اگر status evidence تعیین‌کننده وجود ندارد، claim مربوطه OPEN باقی می‌ماند.
9. Failure Action رفتار پیکربندی‌شده controller است
Windows می‌تواند برای failureهای واجد شرایط actionهایی مانند restart تنظیم کند. این موضوع evidence مفیدی درباره رفتار service controller است، اما با recovery برنامه یکی نیست.
ممکن است restart انجام شود ولی application state هنوز در دسترس یا صحیح نباشد. «restart رخ داد» را از «application recovery verified» جدا بنویس.
10. Running و Ready دو claim متفاوت‌اند
Readiness مخصوص خود application است. ممکن است به local health marker، dependency check یا یک signal محدود دیگر نیاز داشته باشد.
این درس یک health check عمومی تجویز نمی‌کند. فقط می‌خواهد SCM lifecycle evidence با application readiness evidence بی‌صدا یکی نشوند.
11. Dependencyها و concernهای مجاور باید bounded بمانند
Service dependencyها می‌توانند روی startup ordering اثر بگذارند؛ اما وجود dependency در configuration ثابت نمی‌کند هر سیستم بیرونی هنگام شروع کار برنامه سالم است. این درس همچنین full deployment، security، observability یا business correctness را اثبات نمی‌کند.
اگر evidence متعلق به لایه دیگری است، آن را Unknown ثبت کن یا defer کن؛ نه اینکه scope نتیجه را گسترش بدهی.
12. Windows Service Lifecycle Evidence Record v1
این artifact شامل Service Name، Binary/Config، Service Account، Start Type، Dependencies، SCM State، Control Sent، Exit/Error Evidence، Failure Action، Application Health Evidence، Recovery Check، direct observationها، inferenceها، unknownها و تصمیم محدود نهایی است.
هر فیلد تعیین‌کننده باید evidence قابل ردیابی داشته باشد. نبود service identity، lifecycle status یا recovery evidence باعث می‌شود تصمیم مربوطه OPEN بماند.
13. Failure عمدی باید shortcut غلط را آشکار کند
Lab یک case دارد که SCM state به running می‌رسد ولی readiness marker هنوز false است؛ همچنین account-boundary change، benign exit همراه restart، missing status evidence و control-acceptance gap دارد.
این caseها shortcutهایی مثل «running یعنی healthy» یا «restart یعنی recovered» را قبل از بسته‌شدن رکورد رد می‌کنند.
14. Lab و transfer در context تغییرکرده
Lab کاملاً offline و synthetic است. هشت fixture شامل baseline lifecycle، running-but-not-ready، تغییر account boundary، restart بدون recovery، نبود status evidence، demand start، control-handling gap و transfer با context تغییرکرده است.
هیچ real service، administrator credential، production host یا external network لازم نیست. در transfer باید همه stateها از evidence جدید دوباره محاسبه شوند و diagnosis baseline کپی نشود.
15. Source، freshness و مرز claimها
در 2026-09-19 منابع Microsoft Learn مشخص‌شده در Frozen Bible دوباره بررسی شدند. این منابع همچنان SCM را مسئول نگهداری اطلاعات سرویس‌های نصب‌شده، start سرویس‌ها، نگهداری status و انتقال controlها معرفی می‌کنند؛ راهنمای فعلی نیز Windows Service را از سایر background mechanismها تفکیک می‌کند. مسئولیت‌های service entry/status و semantics مربوط به failure action نیز با مرز این درس سازگارند.
این claimهای platform/documentation freshness-sensitive هستند. بازبینی بعدی حداکثر تا 2026-12-31 یا زودتر پس از تغییر مهم در مستندات Microsoft، رفتار Windows یا fixtureها انجام می‌شود. Windows Service Lifecycle Evidence Record v1 طراحی آموزشی MAKNOW است و template رسمی Microsoft نیست.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
OPS-002-S1 retrieval
State the bounded Windows Service lifecycle model and one non-goal.
OPS-002-S2 application
Complete Windows Service Lifecycle Evidence Record v1 for a supplied local fixture using only direct evidence.
OPS-002-S3 diagnosis
Diagnose a running/readiness, service-account, control/status, or failure-action case without changing an unrelated layer.
OPS-002-S4 decision
Defend a bounded lifecycle/recovery conclusion against the shortcuts “running means healthy” and “restart means recovered.”
OPS-002-S5 transfer
Rebuild the record for a changed start mode/account/failure context without copying baseline conclusions.
ملاک‌های ارزیابی (rubric)
A sufficient submission:
- preserves the SCM/configuration/application-health boundaries;
- distinguishes direct observation from inference;
- keeps
SERVICE_RUNNINGseparate from readiness; - keeps configured failure action separate from verified application recovery;
- treats account/resource access as a scoped identity boundary rather than defaulting to broader privilege;
- leaves unsupported conclusions OPEN;
- recomputes the changed-context case independently.
Critical failure occurs when the learner closes a lifecycle or recovery claim without decisive evidence, uses happy-path success as the only proof, or expands the conclusion into an adjacent operational layer.
منابع و تازگی
مطالعهٔ موارد (case studies)
A disposable service fixture has explicit SCM identity, demand/automatic start configuration, account, status, controls, and readiness evidence recorded separately.
SCM reports SERVICE_RUNNING while the application readiness marker is false; treating running as healthy is rejected.
A restricted service-account fixture cannot access a declared resource and the learner keeps the repair scoped to the identity/resource boundary.
A second service uses demand start, a different account and a different benign failure pattern, requiring a fresh lifecycle evidence record.
تصاویر درس
فایل‌های آزمایشگاه
This lab is fully local and synthetic. It models evidence that would be observed from a disposable Windows Service fixture: SCM identity/configuration, start type, service account, lifecycle status, control requests, failure actions, readiness, and recovery verification.
No real service, administrator credential, production host, privileged operation, or external network is required. Do not point the fixture at real infrastructure.
Your task is to implement analyze(case) in starter.py and produce one bounded state for each of the eight dimensions. Keep SCM lifecycle separate from application readiness, and keep restart evidence separate from recovery evidence. Missing decisive evidence must stay OPEN.
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)