انتخاب سردبیر مرکزداده مقالات

پروژه‌های مرکز داده: برنامه‌ریزی سیستم

برنامه‌ریزی پروژه‌های ساخت یا بروزرسانی مراکز داده، همچنان چالشی بزرگ در برابر بسیاری از دپارتمان‌های فاوا به شمار می‌رود. اغلب طرح‌ها با ارتباطات ضعیفی بین ذینفعان مختلف تجاری و داخل سازمان‌ها به اشتراک گذاشته می‌شوند. ممکن است طرح های پیشنهادی با توضیحات زیاد و جزییات فنی، به دست تصمیم‌گیرندگان برسد اما با این حال، همچنان فاقد اطلاعات لازم برای تصمیمات تجاری بهتر باشد. تغییراتی که در مرحله‌ی برنامه‌ریزی ساده به نظر می‌رسند، ممکن است در آینده، در زمان ساخت و اجرای مرکز داده، پیامدهای مهمی بر جای بگذارد. فرایند برنامه‌ریزی و تایید طرح می‌تواند مدت طولانی از برنامه‌ی زمانی پروژه را به خود اختصاص دهد و معمولا حوادث غیرمنتظره و تغییرات نامطلوبی که در اواخر فرایند برنامه‌ریزی رخ می‌دهد، به دوباره‌کاری در برنامه‌ریزی و تاخیرات قابل توجهی در تکمیل پروژه منجر خواهد شد.

بر اساس تجارب به دست آمده از بسیاری از پروژه‌های مراکز داده، تصور می‌شود با دسترسی تصمیم‌گیرندگان به اطلاعات درست در توالی زمانی درست، می‌توان از بسیاری از این مشکلات اجتناب کرد.

در این مقاله، روشی برای برنامه‌ریزی پروژه‌های مراکز داده ارائه شده که کیفیت و سرعت نتایج را ارتقا خواهد بخشید. این روش ساختارمند برنامه‌ریزی، چند گام پی‌ در پی و تصمیمات کلیدی منتج از آن، را معرفی خواهد کرد. با پیروی از این فرایند و معرفی آن به تمام ذینفعان، مدیر پروژه قادر خواهد بود از ابهامات کاسته، ذینفعان را متقاعد سازد که از زمانشان به شکل موثری استفاده شده و میزان مشارکت در سود و زیان پروژه، را بهبود بخشد.

در شکل 1، زمان انجام فرایند برنامه‌ریزی در چرخه‌ی عمر پروژه‌ی مرکز داده، نشان داده شده است. فاز “برنامه‌ریزی” به چهار وظیفه‌ی اصلی در توالی برنامه‌ریزی سیستم، تقسیم می‌شود. توالی برنامه‌ریزی مطرح شده در این مقاله، الزامات طراحی را برای طراحی مهندسی دقیق زیرساخت‌های فیزیکی مرکز داده(که برق سیستم‌های فاوا را تامین‌کرد، سیستم‌ها را خنک کرده، در خود جای داده و از آن محافظت می‌کند) تعیین می کند. البته این توالی برنامه‌ریزی با برنامه ریزی فاوا متفاوت است، بدان معنا که فرایند برنامه ریزی فاوا به موازات این فرایند انجام شده یا پیش از آن اتمام یافته است.

شکل 1: فاز برنامه‌ریزی در قالب چرخه‌ی عمر مرکز داده، نشان‌دهنده‌ی چهار وظیفه‌ی کلیدی در برنامه‌ریزی
شکل 1: فاز برنامه‌ریزی در قالب چرخه‌ی عمر مرکز داده، نشان‌دهنده‌ی چهار وظیفه‌ی کلیدی در برنامه‌ریزی

فازهایی که در شکل 1، با رنگ خاکستری مشخص شده، نشان‌دهنده‌ی تمامی پروژه‌ی مرکز داده است. قسمت برنامه‌ریزی این چرخه‌ی عمر، پایه و اساس قسمت‌های بعدی را شکل می‌دهد. فاز برنامه‌ریزی باید کمترین زمان و کمترین هزینه را به خود تخصیص دهد اما بیشترین تاثیر را بر عملکرد و هزینه‌ی مرکز داده خواهد داشت. فاز برنامه‌ریزی، جزییات سیستم فیزیکی که قرار است ساخته شود، و فرایندهای پروژه سازنده‌ی آن، را تعیین می‌کند. برای دریافت اطلاعات بیشتر در مورد فرایندهای پروژه به گزارش “پروژه‌های مرکز داده: فرایندهای استاندارد”[1] و برای اطلاعات بیشتر در مورد چرخه‌ی عمر پروژه به گزارش “مدیریت چرخه‌ی عمر مرکز داده”[2] مراجعه شود.

توالی برنامه‌ریزی سیستم

توالی برنامه‌ریزی سیستم همان جریان منطقی تفکر، اندیشیدن و داده‌هایی است که ایده‌ی اولیه‌ی پروژه را به مجموعه‌ای از الزامات و مستنداتی تبدیل ساخته که باید عملکرد و هزینه‌ی مرکز داده‌ی ساخته‌شده را کنترل کنند. در اجرای فرایند استاندارد پروژه توسط اشنایدر الکتریک، برنامه‌ریزی سیستم در قالب چهار وظیفه بیان شده که مطابق شکل 1، در طول فاز برنامه‌ریزی پروژه، انجام می‌شود.

جریان فرایند که در این چهار وظیفه بیان می‌شود شامل بعضی ایده‌های کلیدی است که در تجارب موفق پیشین در زمینه‌ی برنامه‌ریزی مرکز داده موثر بوده و پایه و اساس روش این مقاله را شکل می‌دهد. این ایده‌های کلیدی عبارتند از:

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

در اوایل فرایند طراحی باید مشخصا بر اطمینان از ایجاد درکی مشترک و فراگیر از مهم‌ترین قابلیت‌ها و هزینه‌ی مرکز داده تمرکز داشت و از سرمایه‌گذاری بر طراحی جزییات و مشخصات دقیق‌تر اجتناب کرد.

تصمیم‌گیری در مورد مفهوم سیستم شامل آنست که تصمیم‌گیرندگان رده بالا، اهداف اصلی را مشخص کرده و مصالحه‌های اولیه بین عملکرد، هزینه، ابعاد، مکان و برنامه زمانی مرکز داده، صورت گیرد. اگر تا زمان آغاز طراحی جزییات در فرایند پروژه، ذینفعان کلیدی از خصوصیات اصلی طراحی یا هزینه مطلع نباشند، اغلب مشکلاتی بروز خواهد کرد که در این روش، تلاش می‌شود از این مشکلات پیشگیری شود.

جداسازی پارامترهای کلیدی  پروژه از محدودیت‌ها و اولویت‌های کاربر: مجموعه‌ی کوچکی از پارامترهای کلیدی سطح بالایی در پروژه، برای پشتیبانی از انتخاب مفهوم سیستم، ضروری و موثر است. بعضی از این پارامترها شامل مفاهیمی چون ظرفیت و برنامه‌ی رشد و توسعه بوده که پیش از این، به درستی تعریف نشده و با روش‌های مبهمی کمی‌سازی شده است.

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

چهار وظیفه‌ی برنامه‌ریزی

هر یک از چهار وظیفه‌ی اصلی برنامه‌ریزی شکل 1، اطلاعاتی را به عنوان ورودی دریافت کرده و سپس آن را تغییر داده یا جزییات بیشتری بر اطلاعات اولیه افزوده و در نهایت به عنوان خروجی، به وظیفه‌ی بعدی ارسال می‌کند.

در هر گام تکرارهایی صورت گرفته اما هدف از یک فرایند کارامد آنست که دوباره‌کاری به حداقل برسد، به خصوص مشکلاتی که به بازگشت به دو یا چند گام پیشتر در فرایند منجر شده، حذف شوند.

چنین پیشرفتی را می‌توان با استفاده از جریان نمایش داده شده در شکل 2، شبیه‌سازی کرد. داده‌هایی که در این جریان قرار گرفته و تغییر می‌یابد، مفهوم سیستم را توسعه می‌دهد. در شکل 2، داده‌ها به شکل صفحات سفید پایین شکل نمایش داده شده که میان وظیفه‌های مختلف(مستطیل‌های سبز رنگ) متغیر است و در هر گام، ورودی‌های جدیدی از داده‌ها بر داده‌های پیشین اضافه شده و به گام بعدی راه می‌یابد. هر وظیفه، اطلاعات بیشتری فراهم کرده و مجموع این اطلاعات، الزامات طراحی را برای فرایند بعد (مهندسی و طراحی جزییات) فراهم می‌کند. الزامات اجرایی (وظیفه‌ی 4)، وقتی با خروجی‌های حاصل از سه وظیفه‌ی پیش از خود، ترکیب شود، به الزامات جامع طراحی تبدیل خواهد شد و به عنوان “کتاب راهنما” یا دستورالعملی در طراحی جزییات در فاز بعدی طراحی (که در این مقاله نمی‌گنجد) به کار گرفته می‌شود.

شکل 2: چهار وظیفه‌ در "توالی برنامه‌ریزی سیستم"
شکل 2: چهار وظیفه‌ در “توالی برنامه‌ریزی سیستم”

وظیفه‌ی 1: تعیین پارامترهای پروژه

این وظیفه با یک ایده‌ی کلی از نیاز کسب و کار آغاز شده که باید تغییری در توانایی فاوای سازمان ایجاد کند. از این طریق در وظیفه‌ی 1، پارمترهای پروژه که شامل حساسیت، ظرفیت، برنامه‌ی رشد و  توسعه، بهره‌وری، تراکم و بودجه بوده، مشخص می‌شوند. ذینفعان کلیدی که باید در این مرحله مشارکت داشته باشند شامل مدیران مالی، CEO یا مدیر عامل، یکی از مدیران اجرایی اصلی فاوا، مدیر عملیات فاوا و دیگر افرادی است که نیازها و اهداف اصلی کسب و کار را درک می‌کنند. این شش پارامتر پروژه، اهداف سطح بالای پروژه‌ی مرکز داده را تعیین کرده که بعدها، برای توسعه‌ی مفهوم زیرساخت‌های فیزیکی سیستم در مرکز داده، به کار خواهد رفت.

این شش پارامتر کلیدی پروژه، در ادامه توضیح داده شده است:

  1. حساسیت: سطح دسترسی سیستم که در قالب شرایط معمول و استاندارد صنعت، به دست می‌آید.
  2. ظرفیت: بیشترین مصرف فاوا (kW) که زیرساخت‌های فیزیکی مرکز داده قادر به پشتیبانی آن باشند.
  3. برنامه‌ی رشد و توسعه: توصیفی از افزایش در نرخ تولید آتی تا رسیدن به حداکثر الزامات توان که این توضیحات با عدم قطعیت همراه است. (به گزارش “پروژه‌های مرکز داده: مدل رشد”[3] مراجعه شود.)
  4. بهره‌وری: اهداف بهره‌وری انرژی در سیستم‌های زیرساختی مرکز داده.
  5. تراکم: مقدار متوسط توان و اوج مصرف برق (kW/rack) که انتظار می‌رود در رک‌های فاوا مصرف شود و مقدار فضای مورد نیاز (به گزارش ” الزامات محاسبه‌ی فضا و ظرفیت برق برای مراکز داده”[4] مراجعه شود) به همراه اطلاعات مربوط به عدم قطعیت در تراکم.
  6. بودجه: مقدار هزینه‌ی برنامه‌ریزی شده برای هزینه‌ی سرمایه[5] در پروژه.

بسیاری از خطاهای برنامه‌ریزی، طراحی‌های غیر قابل استفاده و خطاهای برنامه زمانی را می‌توان به موارد زیر، ارتباط داد:

  • شکست ذینفعان در دستیابی به درک و توافقی مشترک در مورد این پارامترهای کلیدی در ابتدای فرایند.
  • ذینفعان از مصالحه‌های بین این پارامترها، آگاهی کاملی نداشتند.
  • تا پس از آغاز طراحی جزییات یا حتی تکمیل آن، ذینفعان اطلاعات کاملی از نحوه‌ی انجام طراحی بر اساس این پارامترها دریافت نکرده که در این زمان نیز، اعمال هر گونه تغییری می تواند بسیار هزینه‌بر باشد.

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

ابتدا، باید جلساتی میان رهبر پروژه و ذینفعان (مانند مدیر مالی، مدیر اجرایی فاوا، مدیر اجرایی تاسیسات) برگزار شده تا فرایند توضیح داده شود، زبانی مشترک در مورد این شش پارامتر ایجاد شده، اعضای مشخصی از هر تیم برای شرکت در فرایند تعیین و تایید شوند و هر یک از این افراد را برای جلسات آتی جهت توافق بر این شش پارامتر پروژه، آماده ساخت. با این کار هر عضو تیم می‌تواند درکی مشترک از برنامه داشته و از قبل در مورد این مسائل فکر کرده تا نیازها و نگرانی‌های خود را بررسی کند.

گام دوم:

در گام دوم، یک کارگاه آموزشی برای ذینفعان ترتیب داده تا بر تعیین این 6 پارامتر تمرکز کنند. تصور می‌شود که این کار فرایندی پرتکرار بوده که انتخاب یک پارامتر (مانند حساسیت)، می‌تواند موجب شود پارامتر دیگری (مانند هزینه) مورد قبول واقع نشود که به تغییر در یک یا چند پارامتر دیگر می‌انجامد. به عنوان مثال، با تعیین الزامات ظرفیت (kW) بیش از مقدار مورد نیاز در توسعه‌های آتی فاوا، ممکن است هزینه‌ی پروژه از بودجه‌ی مورد نظر فراتر رفته و نیاز باشد تا با کاهش سطح حساسیت، مقداری در هزینه‌ها صرفه‌جویی کرد.

در این کارگاه، ذینفعان می‌توانند با مشارکت یک کارشناس آگاه یا با استفاده از مدل ریاضی همچون ابزار برنامه‌ریزی مرکز داده (شکل 3)، مصالحه‌هایی آنی بین پارامترهای کلیدی پروژه انجام دهند. از این طریق ذینفعان قادر خواهند بود تا سناریوهای “چه می‌شود اگر…؟” را بررسی کرده و مصالحه‌های بین هزینه‌ی سرمایه، برآورد توان، بهره‌وری و ظرفیت را درک کنند. با کمک چنین ابزار برنامه‌ریزی در کارگاه، دینفعان می‌توانند به درکی مشترک از تاثیرات محدوده‌ی مورد توجه خود(مانند مالی) بر دیگر قسمت‌های پروژه (مانند ظرفیت مرکز داده) دست یابند.

هدف از این جلسات برنامه‌ریزی، تدوین بودجه‌، ظرفیت، برنامه‌ی رشد، بهره‌وری، تراکم و اهداف حساسیت به شکلی واقع‌بینانه است.

البته ممکن است در یک جلسه کارگاه آموزشی، نتوان تمام این 6 پارامتر را تعیین کرد زیرا بعضی از شرکت‌کنندگان، ممکن است به زمان بیشتری نیاز داشته تا تصمیمات مصالحه‌آمیز شناسایی شده را بررسی و تحلیل کنند. اگرچه، در بسیاری موارد، تصمیمات مربوط به کیفیت را می‌توان در عرض چند روز اتخاذ کرد که یکی از اهداف این گام نیز محسوب می‌شود.

شکل 3: صفحه‌ای از ابزار برنامه‌ریزی مرکز داده
شکل 3: صفحه‌ای از ابزار برنامه‌ریزی مرکز داده

وظیفه‌ی 2: توسعه‌ی مفهوم سیستم

m1

در این وظیفه، پارامترهای کلیدی پروژه از وظیفه‌ی پیشین گرفته شده و در انتخاب مفهوم کلی در سیستم زیرساخت‌های فیزیکی از آن استفاده می‌شود. ذینفعان کلیدی که در این مرحله مشارکت دارند، شامل اپراتورهای فاوا، مدیران اجرایی فاوا، مدیران اجرایی تاسیسات، مهندسین تاسیسات و مشاورین با تجربه در برنامه ریزی سیستم در پروژه‌های مرکز داده، می‌باشند. سنگ بنای اصلی در این وظیفه، انتخاب طراحی مرجعی است که دربرگیرنده‌ی حساسیت، ظرفیت، بهره‌وری، تراکم و بودجه‌ی مطلوب بوده و همچنین توسعه‌پذیر است تا از برنامه‌ی رشد و توسعه پشتیبانی کند. علاوه بر آن، در انتهای این گام باید در مورد محل مشخصی (اتاق، ساختمان یا سایت) برای پروژه‌ی مرکز داده، تصمیم نهایی گرفته شود.

در مقایسه با روش سنتی “صفر تا صد” در طراحی مرکز داده، طراحی‌های مرجع آغاز مناسبی در پیش بردن فاز طراحی است. طراحی مرجع یک مدل نمونه از روش طراحی است که ترکیب مشخصی از ویژگی‌های سیستم (همچون حساسیت، توان مصرفی، تکنولوژی تجهیزات، ویژگی‌های توسعه‌پذیری و سطوح اندازه‌گیری)، را در بر می‌گیرد.

علاوه بر آن، یک طراحی مرجع کارامد باید مشخصات عملکردی در سطح سیستم مانند وزن، سطح اشغال و غیره، و همچنین لیستی دقیق از مواد و مصالح یا اجزای تشکیل دهنده‌ی سیستم را نیز در خود داشته باشد. طراحی مرجع بازه‌ای عملی از ظرفیت‌ برق متناسب با طراحی داشته که بدون فرایند زمان‌بر واقعی مشخصات و طراحی، راهی سریع برای ارزیابی موثر گزینه‌های طراحی ارائه می‌دهد. با این طراحی‌ها، می‌توان به سرعت و با بازدهی بالا، تصمیمات با کیفیت بالاتری اتخاذ کرد. برای دریافت اطلاعات بیشتر در مورد طراحی مرجع، به گزارش ” پروژه‌های مرکز داده: مزایای بکارگیری طراحی مرجع”[6] مراجعه شود.

در حالی که تقریبا می‌توان بینهایت طراحی مرجع مختلف را به کار گرفت، اما 6 پارامتر کلیدی پروژه به سرعت بسیاری از آن ها را حذف کرده و فرایند انتخاب طراحی مرجع را به انتخابی ساده بین چند گزینه محدود می‌سازد. به عبارتی دیگر نیازی به فرایند طولانی طراحی متناسب با پارمترهای پروژه که با “طراحی صفر تا صد” آغاز می‌شود، نخواهد بود.

زمانی که تعدادی طراحی مرجع به عنوان گزینه‌های پیشنهادی ارائه شد، می‌توان این گزینه‌ها را مطابق ملاحظات دیگری چون مدیریت دارایی، سابقه‌ی سازندگان، مراجع مشتری و غیره، بررسی کرد.

در بسیاری موارد، مکان پیشنهادی برای مرکز داده از قبل مشخص بوده یا به چند گزینه محدود شده است. انتخاب زودهنگام طراحی مرجع، اطلاعات مورد نیازی فراهم کرده تا تطابق طراحی انتخابی با محل پروژه به سرعت ارزیابی شود. در بررسی عدم تطابق، باید انتخاب طراحی مرجع، گزینه‌های محل پروژه و پارامترهای پروژه را به سرعت با هم مقایسه کرد و برای دستیابی به ترکیبی مطلوب، مصالحه کرد.

در فرایند سنتی طراحی، ممکن است تا آغاز طراحی جزییات هم عدم تطابق تشخیص داده نشده و زمانی ارزشمند از دست رفته که مدیریت را وادار سازد به عقب برگشته و مجددا تصمیمات را بررسی کنند. تمام این مراحل به معنای دوباره‌کاری بوده که در نهایت به تاخیر و هزینه ی اضافی پروژه ختم خواهد شد. توانایی انجام زودهنگام و سریع، مهم‌ترین مصالحه‌ها، با تجزیه‌ی تصمیمات مهم به سه گروه امکان‌پذیر است: 1- شش پارامتر پروژه 2- لیستی محدود از طراحی‌های مرجع و 3- لیستی از گزینه‌های محل پروژه.

اگر مدیر پروژه آمادگی کافی برای انجام این وظیفه داشته باشد، می‌توان آن را طی یک جلسه کارگاه اجرایی تکمیل کرد. برای پروژه‌های کوچک‌تر، وظیفه‌ی 1 و 2 را می‌توان در یک کارگاه انجام داد.

وظیفه‌ی 3: یکپارچه‌سازی محدودیت ها و اولویت های کاربر

m2

محدودیت‌ها و اولویت‌های کاربر شامل الزامات فنی طراحی بوده که در 6 پارامتر کلیدی پروژه لحاظ نشده و در مفهوم سیستم یا انتخاب مکان مشخص نیست. با توجه به انتخاب مفهوم سیستم در وظیفه‌های قبلی، در این وظیفه محدودیت‌ها و اولویت‌های کاربر جمع‌آوری شده، سپس اعتبار آن تایید شده یا به شکلی تغییر یابد که هزینه کاهش یافته و از مشکلات پیشگیری شود.

ایده‌ی اصلی آنست که محدودیت‌ها و اولویت‌های کاربر باید به شکلی انطباق داده شده که با مفهوم انتخابی برای سیستم متناسب باشد.

 

طبق تجربه، اعتبارسنجی و انطباق محدودیت‌ها و اولویت‌های کاربر پس از انتخاب مفهوم طراحی، بسیار موثرتر از آنست که این الزامات را از قبل جمع‌آوری کرده و تلاش شود تا بر اساس آن، طراحی کلی را تعیین کرد. معمولا محدودیت‌ها و اولویت‌های کاربر هستند که به طور ناخواسته، طراحی‌های مرکز داده را از طراحی‌های استاندارد دور کرده، هزینه‌ها را افزایش داده، زمان اجرا را طولانی ساخته و از کیفیت می‌کاهد.

عامل اصلی تعیین کننده در این مرحله، باید شامل عملیات فاوا، مهندسان شبکه، مهنئسان تاسیسات، سایر کارکنانی که هر روزه با فعالیت‌های مرکز داده در ارتباط هستند و مشاورانی با تجربه در زمینه‌ی برنامه‌ریزی سیستم در پروژه‌های مرکز داده، باشد.

محدودیت‌ها و اولویت‌های کاربر به روش زیر تعیین می‌شوند:

  • اولویت‌ها همان نکات مطلوب و مورد نظر کاربر بوده که با توجه به بررسی‌ها (یا بررسی‌های مجدد) هزینه و پیامدها، تغییر یافته یا با طرح سازگار می‌گردند. بعضی اوقات با ارائه‌ی اطلاعات جدید به کاربر، این اولویت‌ها تغییر می‌کنند.
  • محدودیت‌ها در اصل موانعی محسوب می‌شوند که قابل حذف نبوده یا تنها با هزینه‌ای گزاف با پیامدهایی غیرقابل قبول، تغییر می‌کند. محدودیت‌ها شرایطی است که از قبل موجود بوده و تغییر آن دشوار یا غیرممکن است.

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

  • ما کابل‌کشی زیرسقف را ترجیح می‌دهیم.

  • ما نیاز داریم بازدید‌کنندگان بتوانند از مرکز داده بازدید کنند.

  • ما به دوربین‌های امنیتی نیاز داریم تا هر اینچ از فضای مرکز داده را زیر نظر قرار دهیم.

  • ما هرگز نمی‌خواهیم پس از به کار افتادن فضای فاوا، به کابل‌کشی برق یا لوله‌کشی نیاز داشته باشیم.

  • ما استفاده از رک‌های عریض فاوا را جهت تامین فضای بیشتر برای کابل‌ها ترجیح می‌دهیم.

  • ما می‌خواهیم رک‌های فاوا بر اساس مشتری‌شان، جداسازی شده باشند.

  • ما می‌خواهیم خلاصه‌ای از عملکرد انرژی مرکز داده بر دیوار نمایش داده شود.

محدودیت‌ها از طرف شرایط اطراف تحمیل شده و تحت کنترل طراحان مرکز داده نیستند. این محدودیت‌ها شامل محدودیت در تاسیسات و قوانین یا الزامات غیر قابل تغییر کسب و کار است. برای ارزیابی مطابقت تصمیمات موثر بر دستگاه‌های تاسیساتی، با مقررات ملی و منطقه‌ای، به مشاورانی با تجربه نیاز است.

مثال‌هایی از این محدودیت‌ها در ادامه آورده شده است:

  • خصوصیت فیزیکی تاسیسات (مانند ارتفاع دال سقف، ظرفیت تحمل بار کف، هندسه‌ی اتاق، ستون‌ها یا دیوارهای موجود و الزامات نصب دستگاه‌های بیرونی بر بام)

  • مقررات یا قوانینی که باید از آن پیروی شود.

  • استانداردی که باید رعایت شود (مانند TIA 942).

  • قوانین کاری (ساعات دسترسی یا قوانین اتحادیه).

  • خصوصیت فیزیکی در مسیر حمل (مانند ظرفیت تحمل وزن آسانسوری که برای جابجایی تجهیزات به داخل از آن استفاده خواهد شد).

پس از اعتبارسنجی، محدودیت‌ها و اولویت‌های کاربر برای سازگاری با مفهوم انتخابی سیستم بازبینی می‌شوند. در صورتی که سازگاری آن تایید شود به یکی از الزامات طراحی تبدیل می‌شوند. وقتی محدودیت یا اولویت بررسی شده‌ای با مفهوم طراحی مطابقت نداشته باشد، در آن صورت با مصالحه‌های بیشتر، تلاش می‌شود تا با تغییر آن محدودیت یا اولویت یا با تغییراتی کوچک در الزامات، سازگاری کافی با مفهوم سیستم تامین شود(انطباق مفهوم). مطابق شکل 4، به دلیل این تعاملات و مصالحه‌های بین محدودیت‌ها و اولویت‌های مختلف، ممکن است این فرایند شامل چند تکرار باشد.

در اینجا هدف آنست که با انطباق مفهوم سیستم، از بازگشت به مراحل قبلی و بررسی مجدد مفهوم سیستم اجتناب کرده مگر آن که کاملا ضروری باشد.

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

شکل 4: جزییات وظیفه‌ی یکپارچه‌سازی محدودیت‌ها و اولویت‌های کاربر
شکل 4: جزییات وظیفه‌ی یکپارچه‌سازی محدودیت‌ها و اولویت‌های کاربر

باید اطمینان یافت که محدودیت مورد بررسی، واقعا یک محدودیت است. در اینجا دو مثال از راه‌کاری که برای محدودیت ارائه شده است:

محدودیت: عملکرد مرکز داده‌ی موجود فعلی نباید (برای بروزرسانی) متوقف شود و تجهیزات نباید خاموش شوند.

راه‌کار احتمالی: ساخت یک دیوار موقتی برای جداسازی سیستم‌های در حال کار از فضای مخصوص نصب تجهیزات جدید و تامین ورودی برق جداگانه تا هر دو سیستم‌ها را در حین این تغییر، تغذیه کند.

محدودیت: نمی‌توانیم از دستگاه‌های هواکش که به سقف کاذب متصل است استفاده کرد زیرا سقف دارای پلنومی غیر مقاوم در برابر حریق بوده و بازرسین حریق به چنین تاسیساتی مجوز نمی‌دهند.

راه‌کار احتمالی: مواد ضدحریق را بر سطح کانال هوا اسپری کنید.

در بسیاری از موارد، برای دستیابی به مجموعه‌ی نهایی محدودیت‌ها و اولویت‌های کاربر، به تکرارهای معدودی نیاز است. وقتی محدودیت‌ها و اولویت‌ها با مفهوم سیستم سازگاری یافته، تحت عنوان انطباق با سیستم، خلاصه شده و در نهایت اعتبارسنجی و تایید شود، این وظیفه به اتمام می‌رسد. اگر اولویت‌ها و محدودیت‌های کاربر به موازات وظیفه‌های پیشین، جمع‌آوری شوند، این وظیفه در فرایند، سرعت می‌یابد. توجه شود که بسیاری از محدودیت‌ها را تا زمان انتخاب محل پروژه، نمی‌توان شناسایی کرد. در نتیجه ممکن است لازم باشد تا وظیفه‌ی قبلی “توسعه‌ی مفهوم سیستم”، پیش از گردآوری محدودیت‌ها انجام شود.

وظیفه‌ی 4: شناسایی الزامات اجرایی

m3

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

  1. الزامات استاندارد که در میان پروژه‌های مختلف یکسان است. الزامات استاندارد معمولا در قالب مشخصات استانداردی بیان شده که قسمت‌های اصلی از مشخصات مرکز داده را شکل می‌دهند. مثال‌هایی از الزامات استاندارد در واقع هر استاندارد خاص قانونی مانند سازگاری زیرسیستم‌ها، ایمنی، یا تجارب موفق پیشین است که باید رعایت شده و به طور واضحی به مهندسان و نصاب‌ها[7] تفهیم شود.
  2. الزامات پروژه جزییات مورد نظر کاربر را با توجه به اجرای پروژه، تعیین می‌کند. این الزامات شامل ضرب‌الاجل‌ها، محدودیت‌ها یا تخصیص منابع انسانی یا تجهیزات، سازندگان مورد نظر برای همکاری، یا تدارکات خاص، یا دیگر فرایندهای سازمانی است که پروژه باید از آن تبعیت کند.

 جداسازی الزامات اجرایی در دو گروه – گروهی که بین تمام سیستم‌ها مشترک است(الزامات استاندارد) و گروهی که مختص این پروژه‌ی کاربر (الزامات پروژه) است- موجب شده تا روند ایجاد و تطبیق طراحی جزییات سیستم تسهیل شود زیرا بیشتر بازبینی و تصمیمات را می‌توان بر زیرمجموعه‌ای از الزامات مختص پروژه متمرکز ساخت. برای راهنمایی بیشتر به جلد اول “راهنمای تعیین مشخصات سیستم و پروژه: مراکز داده‌ی کوچک و متوسط”[8] مراجعه شود.

الزامات اجرایی وقتی با خروجی‌های تعیین شده در سه وظیفه‌ی قبلی ترکیب شود، به الزامات کامل طراحی تبدیل شده و در فاز بعدی طراحی(که در این مقاله بررسی نشده است) به عنوان یک “کتاب راهنما” یا دستورالعمل در طراحی جزییات مهندسی شده عمل خواهد کرد. در فاز بعدی طراحی، الزامات طراحی که در فرایند برنامه ریزی تعیین شده(در این مقاله بررسی شده)، مهندسی سیستم و پروژه را هدایت خواهد کرد. در این گام بعدی طراحی، مشخصات مهندسی سیستم توسعه می‌یابد که عبارتست از:

  1. لیستی دقیق از اجزا
  2. پلان دقیق از رک‌ها در کف، شامل تجهیزات برق و سرمایش
  3. دستورالعمل‌های دقیق نصب
  4. برنامه‌ی زمانی دقیق پروژه
  5. خصوصیات واقعی “چون ساخت” از طراحی (بهره‌وری، تراکم و توسعه‌پذیری)

همان طور که در این مقاله توصیه شده است، استفاده از طراحی مرجع به عنوان ابزاری در تعیین مفهوم طراحی (البته اگر دربرگیرنده‌ی جزییات کافی باشد)، به طور قابل ملاحظه‌ای طراحی جزییات سیستم را در فاز طراحی تسهیل می‌سازد. طراحی‌های مرجع کارآمد خود شامل بسیاری از موارد لیست فوق هستند در نتیجه، دیگر به تدوین این موارد نیازی نخواهد بود. طراحی‌های مرجع معمولا شامل نمودارهای تک خطی از تاسیسات الکتریکی، مکانیکی، فضای فاوا، جانمایی کف و لیست مواد خام (BOM) بوده و خصوصیات عملکردی مورد انتظار در سطح سیستم ایجاد کرده که معمولا همگی این‌ موارد را می‌توان مستقیما و تنها با کمی تغییر و حداقلِ تحلیل‌ها و مهندسی اضافی، در طراحی جزییات وارد کرده و یکپارچه ساخت.

نتیجه‌گیری

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

در این مقاله، فرایندی برای برنامه‌ریزی مرکز داده معرفی شده که شامل چهار وظیفه است. هر یک از این وظایف، در توسعه و ارتقای مفهوم سیستم، از ایده‌ی اولیه تا الزامات طراحی، نقشی موثر هستند. اصول این فرایند مبنی بر آنست که اطمینان حاصل شود افراد درست با ترتیبی درست، در تصمیم‌گیری درست مشارکت داشته تا بهره‌وری به حداکثر برسد. این توالی این گونه آغاز می‌شود:

نیاز کسب و کار، تعیین کننده‌ی

            پارامترهای پروژه، توسعه دهنده‌ی

                        مفهوم سیستم، تکمیل شده با اعتبارسنجی

                                    محدویت‌ها و اولویت‌های کاربر، ترکیب شده با

                                                                الزامات اجرایی

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

استانداردسازی فرایند برنامه ریزی، وقتی با زبانی مشترک در توصیف الزامات همراه شود، می‌تواند اکثر برنامه‌ریزی‌های مرکز داده را به دانشی قابل پیش‌بینی و تکرارپذیر بدل سازد. با پیروی از فرایندی سازمان یافته، مدیر پروژه قادر خواهد بود از سهل‌انگاری و تصمیمات مبتنی بر اطلاعات نادرست در اویل فاز برنامه ریزی پروژه، اجتناب کرده و اطمینان یابد ذینفعان، از زمان خود به طور اثربخشی استفاده می‌کنند.

 

 

[1] – White Paper 140, Data Center Projects: Standardized Process

[2] – White Paper 195, Managing the Data Center Life Cycle

[3] – White Paper 143, Data Center Projects: Growth Model

[4] – White Paper 155, Calculating Total Space Requirements and Power Density for Data Centers

[5] – بودجه‌ی برنامه‌ریزی، بودجه‌ی پروژه بوده و شامل بودجه‌ی مخارج عملیاتی نمی‌شود. اگرچه، هزینه‌ی عملیاتی، در مصالحه‌ی پارامترها در حین انتخاب مفهوم سیستم، به کار می‌روند.

[6] – White Paper 147, Data Center Projects: Advantages of Using a Reference Design

[7] – تصور می‌شود که مهندسان و معماران از الزامات قوانین اجباری منطقه‌ای اطلاع داشته و از آن پیروی می‌کنند در نتیجه دیگر نیاز به اطلاع‌رسانی در این مورد نیست. هدف از این گام شناسایی استانداردهای خاص داخل سازمانی، اختیاری یا صنعتی است که باید فراتر از الزامات قوانین منطقه‌ای، از آن تبعیت شود.

[8] – System Specification and Project Manual Volume 1: Small and Medium Data Centers

درج دیدگاه

برای درج دیدگاه کلیک کنید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

سوال امنیتی *