نمیتوانید آن را مجازیسازی کنید!
این را در IT همیشه میشنویم؛ یک فروشنده به ما میگوید که یک سیستم نمیتواند مجازیسازی شود. دلایل متعددی وجود دارد. از دیدگاه IT، همیشه شوکه میشویم که فروشندهای چنین ادعای عجیبی مطرح میکند؛ و اغلب به همان اندازه شوکه میشویم که مشتری (یا مدیر) آن را باور میکند. فروشندهها سالهاست که در تکمیل این گفتار فروش تلاش کردهاند و فکر میکنم مهم است که آن را تجزیه و تحلیل کنیم.
علت اصلی مشکلات این است که فروشندهها تقریباً همیشه به دنبال راههایی برای کاهش هزینههای خود در عین افزایش سود از مشتریان هستند. این موضوع بسیاری از رفتارهایی را که در غیر این صورت عجیب به نظر میرسند توضیح میدهد.
یکی از کارهایی که بسیاری از فروشندهها سعی میکنند انجام دهند، محدود کردن سناریوهایی است که محصولشان در آنها پشتیبانی میشود. با این کار، آنها خود را آماده میکنند تا به سادگی پشتیبانی ارائه ندهند – پشتیبانی گران و غیرقابل اعتماد است. این یک استراتژی رایج است. در برخی موارد، این قدر تهاجمی است که هیچ سناریوی قابل قبول و تولیدیای وجود ندارد.
یکی از روشهای بسیار رایج برای این کار، عدم پشتیبانی از هیچ سیستمعاملی است که واقعاً پشتیبانی میشود، که بهطور ضمنی نرمافزار خود فروشنده را منسوخ میکند (برای مثال، امروز این به معنای پشتیبانی تنها از Windows XP و نسخههای قدیمیتر بود). مثال دیگر، پشتیبانی تنها از محصولاتی است که برای موارد استفاده مجوز ندارند (مثلاً نیاز به استفاده از Windows 10 به عنوان سرور). و یکی از رایجترین موارد، منع مجازیسازی است.
این سناریوها مشتریان را در موقعیتهای دشواری قرار میدهند؛ چرا که از یک سو، بهترین روشهای صنعت، دستورالعملهای استاندارد استقرار، ابزارها و سیاستهای داخلی وجود دارند که باید رعایت شوند؛ و از سوی دیگر، فروشندهها اغلب طراحی، برنامهریزی و مدیریت صحیح سیستم را ممنوع میکنند. این نیازها با یکدیگر در تضاد هستند.
البته، هیچکس انتظار ندارد که هر فروشندهای از هر سناریوی احتمالی پشتیبانی کند. محدودیتها باید اعمال شوند. اما فاصلهای بزرگ وجود دارد بین پشتیبانی از سیستمهای معقول و بهدرستی مستقر شده و نیاز فعال به استقرارهای بسیار بد. ما امیدواریم که فروشندههایمان به عنوان شرکای تجاری رفتار کنند و در موفقیت ما یا حداقل در موفقیت محصولشان علاقه مشترکی داشته باشند و مستقیماً در تضعیف این اهداف نباشند. ما انتظار داریم که حداقل، برای هر سناریوی استقرار معقول پشتیبانی با حسن نیت ارائه شود و برای سناریوهای مهندسیشده و مطابق با بهترین روشها، پشتیبانی تضمینشده ارائه شود.
تصور کنید دنیایی که رانندگی با سرعت مجاز و بستن کمربند ایمنی ضمانت خودروی شما را باطل میکند و تنها در صورتی پشتیبانی دریافت میکنید که بیاحتیاطانه و بدون محافظت رانندگی کنید!
برخی نکات مهم باید در مورد مجازیسازی درک شوند. اولین مورد این است که مجازیسازی یک بهترین روش صنعتی دیرینه است و انتظار میرود در هر سناریوی استقرار تولیدی برای سرویسها استفاده شود. مجازیسازی به هیچ وجه جدید نیست، حتی در بازار کسبوکارهای کوچک بیش از یک دهه است که در دسته بهترین روشها قرار دارد و در فضای سازمانی برای چندین دهه بوده است. ما از مرحلهای گذشتهایم که اجرای سیستمها بدون مجازیسازی قابل قبول به نظر برسد، و این شامل استقرارهای قدیمیای است که مدت زیادی در محل بودهاند.
البته، استثناهای نادری تقریباً برای هر قانونی وجود دارند. برخی سیستمها به دسترسی به سختافزار بسیار خاص نیاز دارند و مجازیسازی ممکن است امکانپذیر نباشد، هرچند با عبور مستقیم سختافزار مدرن این تقریباً ناشنیده است. و برخی سیستمهای با تأخیر فوقالعاده پایین نمیتوانند مجازیسازی شوند، اما اینها معمولاً تنها به بزرگترین بانکهای سرمایهگذاری بینالمللی و تهاجمیترین صندوقهای پوشش ریسک محدود میشوند و حتی اکثر آن موارد استفاده سنتی با پیشرفتهای مجازیسازی حذف شدهاند. اما خلاصه کلام این است که اگر نمیتوانید مجازیسازی کنید، باید ناراحت باشید که نمیتوانید، و دلیل اینکه چرا در وضعیت شما غیرممکن است را به وضوح میدانید. در تمام موارد دیگر، سرور شما باید مجازی باشد.
آیا مهم نیست؟
اگر یک فروشنده اجازه نمیدهد که از بهترین روشهای استاندارد برای استقرارهای سالم پیروی کنید، این در مورد نظر فروشنده درباره محصول خودش چه میگوید؟ اگر درباره هر استقرار دیگری صحبت میکردیم، فوراً این سؤال را میپرسیدیم که چرا یک سیستم را به این شکل ضعیف مستقر میکنیم اگر قرار است به آن متکی باشیم. اگر فروشندهای ما را مجبور به این رفتار کند، باید به همان شیوه واکنش نشان دهیم – اگر فروشنده محصول را به همان درجهای که ما کمترین سرویسهای IT خود را جدی میگیریم نمیگیرد، چرا ما باید بگیریم؟
این یک «عدم تطابق امپدانس» است، همانطور که در محافل مهندسی میگوییم، بین نیازهای ما (سیستمهای تولیدی) و نحوهای که فروشنده ظاهراً آن سیستم را در نظر میگیرد (سیستمهای سرگرمی یا تفریحی). اگر باید به این محصول برای کسبوکارمان متکی باشیم، به فروشندهای نیاز داریم که همسو باشد و نیازهای کسبوکار را درک کند – ذهنیت تولیدی داشته باشد. اگر محصول هدف کسبوکار نیست یا آماده کسبوکار نیست، باید از آن آگاه باشیم. باید این سؤال را مطرح کنیم که چرا احساس میکنیم باید از سرویسی در تولید استفاده کنیم که به آن متکی هستیم و نیاز به پشتیبانی داریم، در حالی که قرار نیست به این شکل استفاده شود.
آیا پشتیبانی میشود؟ آیا آزمایش میشود؟
چیزی که اغلب از دیدگاه مشتریان نادیده گرفته میشود این است که آیا منابع پشتیبانی لازم برای یک محصول وجود دارند یا نه. معمول نیست که تیم پشتیبانی یک محصول کوچک شود یا حتی ناپدید شود، اما شرکت به فروش محصول ادامه دهد به امید بهرهمندی از آن تا جایی که بتواند و یا از پس مشکلات بربیاید یا فقط در صورتی که در وضعیتی گیر کنند که توانایی پشتیبانی ندارند، وجه مشتریان را بازگرداند.
اکثر قراردادهای نرمافزاری بیان میکنند که حداکثر خسارتی که میتوان از فروشنده دریافت کرد، هزینه محصول یا مبلغی است که برای خریدش پرداخت شده. در چنین حالتی، فروشنده هیچ ریسکی از ارائه محصولی که نمیتواند از آن پشتیبانی کند ندارد – حتی اگر برای پشتیبانی هزینهای اضافی دریافت کند. اگر مشتری موفق به استفاده از محصول شود، عالی است، پول دریافت میکنند. اگر مشتری نتواند و فروشنده نتواند از آن پشتیبانی کند، تنها پولی را از دست میدهند که هرگز به دست نمیآوردند. مشتری تمام ریسک را میپذیرد، نه فروشنده.
این البته نشان میدهد که آزمایش مستمر محصول نیز وجود ندارد یا بسیار اندک است، و این باید نگرانی بیشتری ایجاد کند. صرفاً اینکه محصول اجرا میشود به معنای ادامه اجرای آن نیست. راهاندازی و اجرا با یک محصول پشتیبانینشده، یا بدتر، غیرقابل پشتیبانی، به این معنی است که به مرور زمان بیشتر و بیشتر به محصولی متکی میشوید که سطح پشتیبانی بالقوه آن احتمالاً در حال کاهش است و به تدریج بدتر میشود، حتی در حالی که انتظار میرود نیاز به پشتیبانی و وابستگی به نرمافزار افزایش یابد.
اگر یک محصول اختصاصی در تولید مستقر شود و تصمیم گرفته شود که از بهترین روشهای استقرار صرف نظر شود تا درخواستهای پشتیبانی برآورده شوند، چگونه میتوان این را در ماتریس تصمیمگیری قرار داد؟ آیا این به این معناست که پشتیبانی مناسب وجود ندارد؟ دوباره، همانند قبل، این نشانگر عدم تطابق با نیازهای ماست.
آیا هنوز توسعه داده میشود؟
اگر نیازهای استقرار نرمافزار از روشهای قدیمی و منسوخ پیروی کنند، یا به نرمافزار یا طراحی قدیمی (یا بهروز نشده) نیاز داشته باشند، باید احتمال اینکه محصول در حال حاضر توسعه داده میشود را زیر سؤال ببریم. در برخی موارد میتوانیم این را با مشاهده چرخه انتشار نرمافزار برای مدتی تعیین کنیم، اما نه در همه موارد. نگرانی معقولی وجود دارد که محصول ممکن است مرده باشد و هیچ تیم توسعه فعالی روی آن کار نکند. کد ممکن است صرفاً قدیمی و بدهی فنی باشد که با امید دریافت آخرین پولها از یک پایه کد قدیمی رها شده به فروش میرسد. این فرآیند در واقع بسیار رایجتر از چیزی است که اغلب تصور میشود.
فروشگاههای نرمافزاری کوچکتر اغلب موفق میشوند یک بسته نرمافزاری اولیه توسعه دهند، آن را به بازار برسانند و برای فروش در دسترس قرار دهند، اما نمیتوانند پس از انتشار(های) اولیه تیم توسعه خود را حفظ کنند یا تجدید استخدام کنند. این در واقع یک سناریوی بسیار رایج است. این مشتریان را با محصولی روبرو میکند که انتظار میرود به مرور زمان کمتر و کمتر قابل استفاده شود و سناریوهای استقرار به طور فزایندهای ریسکپذیر و استخراج داده به طور فزایندهای سختتر شود.
چگونه میتوان از آن پشتیبانی کرد اگر پلتفرم پشتیبانی نمیشود؟
یک تناقض رایج در برخی موقعیتهای شدیدتر، نرمافزاری است که برای واجد شرایط بودن به عنوان «پشتیبانیشده»، به نرمافزار دیگری نیاز دارد که یا از پشتیبانی خارج شده یا هرگز برای مورد استفاده مورد نظر پشتیبانی نشده. مثالهای رایج شامل نیاز به اجرای یک سیستم سرور بر روی یک سیستمعامل دسکتاپ یا نیاز به نسخههایی از سیستمعاملها، پایگاههای داده یا سایر اجزا است که دیگر اصلاً پشتیبانی نمیشوند. این سناریوی آخر به طرز ترسناکی رایج است. در چنین وضعیتی، باید پرسید که آیا میتوان هرگز استقراری داشت که در آن نرمافزار «پشتیبانیشده» محسوب شود؟ اگر بخشی از پشته همیشه خارج از پشتیبانی است، کل پشته پشتیبانینشده است. همیشه دلیلی وجود خواهد داشت که پشتیبانی بتواند رد شود، مهما باشد. همان دلیلی که ما بنابراین از بهترین روشها اجتناب میکنیم به طور مساوی انتخاب خود نرمافزار را در وهله اول رد میکند.
آیا مهارتها و دانش صنعتی کافی نیستند؟
شاید مشکلی که با مشکلات پشتیبانی نرمافزار از این نوع روبرو هستیم این باشد که تیم(های) ایجادکننده نرمافزار به سادگی نمیدانند که نرمافزار خوب چگونه ساخته میشود و/یا سیستمهای خوب چگونه مستقر میشوند. این از جمله معقولترین و معتبرترین دلایلی است که میتواند ما را به این وضعیت برساند. اما مانند سایر دلایل فرضی، ما را نگران کیفیت نرمافزار و احتمال اینکه پشتیبانی واقعاً در دسترس باشد میکند. اگر نمیتوانیم به فروشنده اعتماد کنیم که قابل مشاهدهترین بخشهای سیستم را به درستی مدیریت کند، چرا باید آنها را به عنوان متخصصان خود برای بخشهایی که نمیتوانیم تأیید کنیم انتخاب کنیم؟
مشکل بزرگ
مشکل بزرگ و فراگیر با نرمافزاری که درخواستهای استقرار و نگهداری مشکوک دارد و در ازای باز کردن پشتیبانی که در غیر این صورت داده نمیشود، نه آنطور که معمولاً فرض میکنیم، سؤالی از کیفیت کلی نرمافزار است، بلکه مسئلهای از شیوههای پشتیبانی و توسعه قابل دوام است. اینکه این مسائل نگرانی قابل توجهی برای پشتیبانی بلندمدت نشان میدهند باید ما را به شدت وادار کند که زیر سؤال ببریم چرا اصلاً این بستهها را انتخاب میکنیم در حالی که از همان ابتدا نگرانیهای بسیار آشکار و جدی داریم.
البته مواردی وجود دارند که هیچ محصول نرمافزاری دیگری برای برآوردن یک نیاز وجود ندارد یا هیچ کدام با قابلیت معقولتری موجود نیست. این وضعیت باید بسیار نادر باشد و اگر چنین وضعیتی وجود داشته باشد باید به عنوان یک فرصت بزرگ بازار برای فروشندهای که میخواهد وارد آن فضا شود دیده شود.
از دیدگاه تجاری، ضروری است که بهترین روشهای زیرساخت فنی به طور کامل نادیده گرفته نشوند در ازای پیروی کورکورانه یا تقریباً کورکورانه از الزامات فروشنده که در هر مورد دیگری بیاحتیاطانه یا غیرحرفهای محسوب میشوند. چرا اغلب از نیاز به برتری از محصولات اصلی که کسبوکارمان به آنها وابسته است به این شکل غافل میشویم؟ این کسبوکار ما را در معرض ریسک قرار میدهد، نه فقط از خود عمل، بلکه بسیار بیشتر از ریسکهایی که توسط وجود چنین الزامی ضمنی هستند.
آگهی
