Assessment موفق با فهرستکردن داراییها تمام نمیشود. خروجی باید نشان دهد سازمان برای کدام مسیر آماده است، چه Gapهایی باید بسته شوند، کدام ریسکها پذیرفتنیاند و ترتیب اقدامها چگونه است.
Inventory میگوید چه داریم؛ Assessment میگوید چه باید بکنیم
فهرست Host، VM، Datastore و نسخه نرمافزار برای شروع لازم است، اما برای تصمیم کافی نیست. دو سازمان با Inventory مشابه ممکن است به نتایج کاملاً متفاوت برسند؛ چون SLA، محدودیت Downtime، رشد ظرفیت، ساختار تیم، وابستگی برنامهها و مدل خرید آنها یکسان نیست.
Assessment باید داده فنی را به سؤال مدیریتی وصل کند: آیا محیط فعلی قابل ارتقاست؟ چه بخشی باید اصلاح یا جایگزین شود؟ کدام تصمیم قبل از خرید Hardware یا License باید گرفته شود؟ چه ریسکی میتواند Change Window را متوقف کند؟ و حداقل Roadmap قابل دفاع برای رسیدن به Production چیست؟
خروجی واقعی Assessment
یک پاسخ مستند به سه سؤال: «اکنون کجا هستیم؟»، «برای مسیر هدف چه فاصلهای داریم؟» و «کمریسکترین ترتیب اقدام چیست؟»
چه زمانی Assessment ارزش بیشتری ایجاد میکند؟
بهترین زمان ارزیابی پیش از قفلشدن تصمیمهای پرهزینه است؛ یعنی قبل از نهاییشدن BOM، تمدید لایسنس، انتخاب نسخه هدف یا اعلام Change Window. اگر Assessment پس از خرید انجام شود، ممکن است فقط برای توجیه تصمیم قبلی استفاده شود و آزادی اصلاح معماری کاهش پیدا کند.
پیش از خرید یا تمدید
برای تطبیق Core، SKU، ظرفیت و معماری با نیاز واقعی.
پیش از Upgrade
برای مشخصکردن Upgrade Path، Compatibility و Remediation.
پیش از Migration
برای کشف Dependency، Wave، Cutover و Rollback.
پس از رشد یا تغییر سازمان
برای بازبینی Capacity، Ownership، Security و Operating Model.
Baseline معتبر چگونه ساخته میشود؟
Assessment باید یک Freeze Date داشته باشد. در آن تاریخ، نسخهها، Buildها، Firmware، ظرفیت، Configuration و Scope ثبت میشوند. تغییرات بعدی نیز جداگانه مستند میشوند تا تیم فنی نداند کدام داده متعلق به قبل و کدام مربوط به زمان اجرای پروژه است.
دادهها از چند منبع جمع میشوند: Export ابزارهای مدیریتی، Configuration، Performance History، مصاحبه با Ownerها، مستندات شبکه و Storage، قراردادهای License و Support، گزارشهای Incident و مشاهده فرآیند واقعی Change. هر یافته باید به Evidence قابل بازبینی متصل باشد.
- دارایی و نسخه بدون Build یا Firmware دقیق، Baseline کامل نیست.
- ظرفیت بدون Peak، Trend و Headroom قابل تفسیر نیست.
- SLA بدون سرویس و Owner مشخص، معیار تصمیم نیست.
- Dependency بدون منبع و درجه اطمینان نباید قطعی فرض شود.
هشت دامنهای که همزمان ارزیابی میشوند
| دامنه | سؤال اصلی | نمونه Evidence |
|---|---|---|
| Platform و Version | نسخهها و Buildها با Target Path سازگارند؟ | vCenter/ESX/SDDC Manager/NSX Inventory |
| Hardware و Firmware | Host، CPU، NIC، Controller و Drive در ماتریس معتبر قرار دارند؟ | OEM Inventory، Firmware Baseline، Compatibility |
| Compute و Capacity | مصرف، Contention و Headroom برای رشد چقدر است؟ | Performance History و Capacity Trend |
| Storage | Availability، Latency، Policy، Failure Domain و ظرفیت قابلاستفاده چگونهاند؟ | Datastore/vSAN Health، Policy و Error Log |
| Network و NSX | Underlay، MTU، Routing، Edge و Segmentation آمادهاند؟ | Topology، Switch Config و NSX Export |
| Backup و DR | RPO/RTO، Protection Scope و Restore واقعی قابل دفاع است؟ | Backup Report، Restore Test و DR Runbook |
| Licensing و Commercial | Core، Entitlement و Scope خرید با Design هماهنگ است؟ | Contract، Quote و Core Workbook |
| Operations و Team | مالکیت، مهارت، Monitoring، Change و Escalation مشخص است؟ | RACI، SOP، Ticket و مصاحبه |
هر یافته باید Owner، Severity و Evidence داشته باشد
فهرست طولانی از مشکلات بدون اولویت، تصمیمگیر را فلج میکند. هر Gap باید با اثرش روی مسیر هدف سنجیده شود. ممکن است یک ناسازگاری Firmware مانع قطعی Upgrade باشد؛ درحالیکه یک کمبود مستندات، اجرای فنی را متوقف نکند اما ریسک تحویل و پشتیبانی را بالا ببرد.
| فیلد یافته | معنا |
|---|---|
| Observation | چه چیزی مشاهده شده است؛ بدون تفسیر مبهم. |
| Evidence | منبع قابل بازبینی و تاریخ ثبت. |
| Impact | اثر روی Availability، Security، Cost، Schedule یا Support. |
| Severity | شدت براساس احتمال و پیامد، نه سلیقه ارزیاب. |
| Recommendation | اقدام پیشنهادی و گزینه جایگزین. |
| Owner و Due Date | مسئول تصمیم یا اصلاح و زمان مورد انتظار. |
چگونه یافتهها به تصمیم اجرایی تبدیل میشوند؟
پس از تحلیل، Gapها در چهار دسته قرار میگیرند: Blocker، Remediation قبل از پروژه، اقدام قابل انجام در حین اجرا و Backlog پس از Go-Live. سپس چند مسیر مقایسه میشوند؛ برای نمونه Upgrade محیط موجود، Converge، Greenfield یا حفظ وضعیت فعلی در یک بازه مشخص.
مقایسه باید فقط فنی نباشد. هزینه License و Hardware، مدت آمادهسازی، نیاز به Migration، ریسک Downtime، مهارت تیم و قابلیت پشتیبانی بعدی کنار هم قرار میگیرند. نتیجه، Recommendation تکخطی نیست؛ یک Decision Pack است که فرضها و عدمقطعیتها را هم نشان میدهد.
فرآیند VCF Assessment راگا
- Kickoff و Scope: هدف، Stakeholderها، محیطها، دسترسی و معیار موفقیت تعیین میشود.
- Discovery: دادههای Platform، Hardware، Network، Storage، License و Operations جمعآوری میشوند.
- Workshop: تیمهای فنی و کسبوکار درباره SLA، محدودیت و برنامه رشد همراستا میشوند.
- Validation: ناسازگاریها، Dependencyها و موارد مبهم با Owner مربوط کنترل میشوند.
- Option Analysis: مسیرهای ممکن با Risk، Cost، Time و Operability مقایسه میشوند.
- Roadmap: Remediation، خرید، Design، Pilot و اجرای Production مرحلهبندی میشوند.
- Executive Review: تصمیمها، ریسکهای پذیرفتهنشده و اقدام بعدی با Sponsor مرور میشوند.
خروجیهایی که تیم مدیریت و فنی هر دو میتوانند استفاده کنند
- Executive Summary و پیشنهاد مسیر
- Current-State Architecture و Inventory معتبر
- Compatibility و Hardware Readiness Workbook
- Gap Register، Risk Register و Remediation Backlog
- Core و Licensing Assumption Workbook
- Target-State Options و Decision Log
- Roadmap مرحلهای با Dependency و Owner
- فهرست دادههای ناموجود و موارد نیازمند Sign-off
این خروجیها باید مبنای مرحله بعد باشند. اگر پروژه به Design برسد، Assessment ورودی HLD/LLD است؛ اگر خرید مطرح باشد، ورودی BOM و Quote است؛ و اگر Upgrade انتخاب شود، مبنای Precheck و Runbook خواهد بود.
سناریوی نمونه؛ وقتی ظاهر محیط آماده است اما مسیر هنوز قطعی نیست
فرض کنید سازمان چند Cluster پایدار، Storage خارجی و شبکه VLAN-Based دارد. نسخهها نزدیک به Target هستند، اما بخشی از VMkernelها روی Standard Switch قرار دارند، Firmware چند Host ناهماهنگ است و تعداد Coreهای پردازنده نسبت به بار واقعی بالاست. در نگاه اول Upgrade ساده به نظر میرسد.
Assessment نشان میدهد مشکل اصلی Version نیست؛ ترکیب Network Remediation، Hardware Economics و Operating Model است. ممکن است ارتقای محدود برخی Hostها، اصلاح Distributed Switch و بازطراحی Cluster مرزی، هزینه و ریسک کمتری از یک تصمیم یکپارچه و عجولانه داشته باشد. این سناریو صرفاً برای توضیح روش تصمیمگیری است و به پروژه یا مشتری واقعی اشاره ندارد.
Assessment چه چیزی نیست و چه وعدهای نمیدهد؟
Assessment جای Design تفصیلی، Pilot، Penetration Test یا اجرای Upgrade نیست. همچنین بدون دسترسی کافی نمیتواند درباره Compatibility، Dependency یا Downtime نتیجه قطعی بدهد. مواردی که Evidence ندارند باید با درجه اطمینان مشخص گزارش شوند.
هیچ عدد یا نتیجه عملکردی بدون مستند و تأیید تیم فنی در این صفحه منتشر نمیشود. Build-Level Compatibility و Licensing نیز در زمان پروژه دوباره کنترل خواهند شد.
منابع و مبنای فنی
مبنای نسخه و مسیر، اسناد رسمی Broadcom/VMware است: راهنمای Pathways to VCF ۹.۱ و Feature Comparison و Upgrade Paths. این صفحه جای Compatibility Guide و Planning Workbook همان Build را نمیگیرد.