نوشته ها در دسته بندی: آموزش

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

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

جف هاپکینز، یکی از مدیران شرکت مشاوره مالیاتی و حسابرسی RSM، می‌گوید از مزایای غیر سنتی با موفقیت برای حفظ استعدادهای فناوری اطلاعات استفاده شده است. او خاطرنشان می کند: «چالش، شناسایی و ایجاد این امتیازات متناسب با سازمان IT شما است.»

رایگان و قابل انعطاف

داون دونچ، مدیر مردم و فرهنگ در ارائه‌دهنده فناوری محیط کار دیجیتال Igloo Software، می‌گوید ساعات کاری انعطاف‌پذیر و کار از راه دور امتیازات بسیار مهمی هستند. او می‌گوید: «تقریباً همه استخدام‌شدگان جدید نرم‌افزار Igloo، به ویژه کارکنان فناوری اطلاعات، به دنبال کار انعطاف‌پذیر هستند». “نامزدهایی که ما با آنها مصاحبه می کنیم در مورد موضع ما در مورد کار انعطاف پذیر در طول فرآیند استخدام می پرسند.”

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

برخی از تیم‌های شبکه در تغییر از گفتن دستگاه‌ها چه کاری انجام دهند، با استفاده از برنامه‌نویسی ضروری، به توصیف آنچه که باید باشند، با استفاده از برنامه‌نویسی اعلامی، قدرت و سادگی پیدا می‌کنند. Nemertes اخیراً به چگونگی پیاده‌سازی اتوماسیون شبکه توسط سازمان‌هایی با شبکه‌های بزرگ‌تر-مخصوصاً شبکه‌های سنگین Cisco- پرداخت. نتایج کمی شگفت‌انگیز بود زیرا کمتر از 20 درصد از کنترلر و داشبورد مدیریت شبکه DNA مرکز سیسکو استفاده می‌کنند که می‌تواند تدارکات و مدیریت تغییر را خودکار کند.

از طرف دیگر، بیش از 40٪ راه حل های اتوماسیون خود را با استفاده از اشکال مختلف برنامه نویسی یا برنامه نویسی ضروری (عمدتا پایتون) ارائه می دهند و حدود 50٪ به جای یا علاوه بر آن از یک مدل متفاوت استفاده می کنند: اتوماسیون اعلامی.

برنامه نویسی ضروری

ایده برنامه‌نویسی ضروری نوشتن برنامه‌هایی است که مجموعه‌ای از دستورالعمل‌ها هستند، مانند “A را انجام دهید سپس B را انجام دهید سپس اگر X اتفاق افتاد C را انجام دهید در غیر این صورت E را انجام دهید.” اکثر زبان های برنامه نویسی که بیشترین استفاده را دارند ضروری هستند (C++، C#، PHP و Python). روند فعلی برای اتوماسیون شبکه بیشتر، بسیاری از متخصصان شبکه را وادار می کند تا مهارت های قدیمی برنامه نویسی را حذف کنند یا برای اولین بار آنها را انتخاب کنند.

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

برنامه نویسی اعلانی

برخی از کارکنان شبکه، رویکردهای اعلامی را مناسب تر می دانند. برنامه نویسی اعلانی به جای گام هایی که برای دستیابی به آن باید برداشته شود، بر تعریف نتیجه مطلوب برنامه تمرکز دارد. HTML را می توان یک زبان اعلامی در نظر گرفت – “این صفحه وب باید دارای این متن در این اندازه و تصویر زیر و دو دکمه در اینجا و اینجا باشد تا کاربران را به صفحات B و C برساند.” SQL نیز می تواند – “مجموعه داده باید شامل تمام رکوردهایی باشد که شرایط A و B و C را برآورده می کنند.”

رویکردهای اعلامی برای اتوماسیون شبکه، بار زیادی از بار برنامه نویسی را بر عهده مهندسان شبکه می گذارد. افراد می توانند به جای کشف دستورالعمل های دقیق برای دستیابی به آن پیکربندی به درستی، بر نحوه پیکربندی یک دستگاه یا سرویس تمرکز کنند. یعنی می‌توانند روی عباراتی مانند «پورت‌های 1 تا 24 باید به صورت دوطرفه کامل 1 گیگابیت بر ثانیه پیکربندی شوند» تمرکز کنند. پورت های 1 تا 12 روی VLAN A هستند. پورت های 13 تا 24 روی VLAN B هستند.

مطالعه تحقیقاتی اتوماسیون شبکه Nemertes در سال 2022 نشان داد که 33٪ از سازمان های مورد مصاحبه از Ansible برای اتوماسیون شبکه و 17٪ از Gluware استفاده می کردند. Ansible عمدتاً در نتیجه رشد DevOps و پارادایم زیرساخت به عنوان کد مرتبط با DevOps برجسته شده است. در اولین نسخه‌های خود از یک مدل کاملاً ضروری استفاده می‌کرد، اما حدود پنج سال پیش پشتیبانی از مدل‌های اعلامی را نیز اضافه کرد. تیم های شبکه آن را به عنوان وسیله ای برای خودکارسازی مدیریت شبکه در شبکه های مرکز داده و شعبه/پردیس استفاده کرده اند. Gluware به طور خاص به عنوان یک ابزار اتوماسیون شبکه و در درجه اول برای شبکه های سیسکو محور تکامل یافته است.

مدل‌های اعلامی برای اتوماسیون شبکه

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

با این حال، طرف دیگر آن این است که سازمان باید کاملاً به پلتفرم متکی باشد که بتواند به درستی ابزار را در شبکه خود پیکربندی کند. این معمولاً برای بزرگترین فروشندگان و تجهیزات نسبتاً جدید آنها یک فرض مطمئن است، اما برای فروشندگان کوچکتر یا تجهیزات قدیمی یا نسخه‌های قدیمی‌تر سیستم‌عامل‌های قدیمی‌تر، چندان مطمئن نیست. شایان ذکر است که در مطالعه Nemertes، که بر کسب اطلاعات در مورد مدیریت شبکه سیسکو متمرکز بود، تنها 25٪ از سازمان ها دارای مسیریابی و سوئیچینگ تمام سیسکو بودند. بیشتر سازمان ها دو یا سه فروشنده درگیر بودند.

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

4 بهترین شیوه شبکه سازی که از قطع شدن شبکه Atlassian آموخته شد. ماه گذشته، فروشنده ابزارهای نرم افزاری Atlassian دچار قطعی شبکه شد که دو هفته به طول انجامید و بیش از 400 نفر از بیش از 200000 مشتری آنها را تحت تأثیر قرار داد. این قطعی باعث از بین رفتن چندین محصول آنها از جمله Jira، Confluence، Atlassian Access، Opsgenie و Statuspage شد.

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

خطاهای داخلی و اشتباهات

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

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

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

شرح جزئیات دقیق

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

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

درس هایی از این حادثه گرفته شد

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

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

درس 1: ارتباطات داخلی و خارجی را بهبود بخشید

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

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

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

این به مشتریان این امکان را می داد که حتی بدون بازه زمانی مشخص، برنامه ریزی بهتری در مورد حادثه داشته باشند. “ما باید عدم اطمینان خود را در ارائه تاریخ بازسازی سایت زودتر می پذیرفتیم و زودتر خود را برای گفتگوهای حضوری در دسترس قرار می دادیم تا مشتریان ما بتوانند بر اساس آن برنامه ریزی کنند. ما باید در مورد آنچه که در مورد قطع برق می‌دانیم و آنچه نمی‌دانیم شفاف می‌بودیم.»

درس 2: از داده های مشتری محافظت کنید

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

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

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

در اعترافات وبلاگ، آنها روند مدیریت حادثه در مقیاس بزرگ قبلی خود را ترسیم می کنند – می توانید ببینید که قطعات متحرک زیادی دارد و در حد وظیفه “کنترل عمق، گستردگی و مدت حادثه آوریل” نبود.

درس 3: سناریوهای پیچیده بازیابی فاجعه را آزمایش کنید

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

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

درس 4: از داده های پیکربندی محافظت کنید

در نهایت، این مسئله در مورد نحوه حذف داده ها وجود دارد که باعث شروع کل قطعی شد. آنها اکنون متوجه شده اند که حذف داده ها، به خصوص کل سایت، نباید مجاز باشد. Atlassian در حال حرکت به سمت چیزی است که آنها آن را “حذف نرم” می نامند، که بلافاصله داده ها را از بین نمی برد تا زمانی که با بازگردانی های تعریف شده سیستم بررسی شود و از تعدادی حفاظتی عبور کند.

Atlassian در حال ایجاد یک سیاست “حذف نرم جهانی” در تمام سیستم های خود و ایجاد یک سری استانداردها و بررسی های داخلی است. گزینه soft delete چیزی بیش از یک گزینه است. هیچ داده پیکربندی را تا زمانی که آن را در سراسر زیرساخت خود آزمایش نکرده اید حذف نکنید.

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

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

چشم انداز فعلی فناوری ذخیره سازی

به گفته تانگ ژانگ، پروفسور مؤسسه پلی‌تکنیک Rensselaer و همچنین یکی از بنیان‌گذاران و دانشمند ارشد ScaleFlux، فناوری، مدل استقرار و مسائل بین‌صنعتی همگی به تکامل ذخیره‌سازی داده‌ها کمک می‌کنند. افزایش فناوری های جدید و شتاب بیشتر در رشد تولید داده نیز فناوری های ذخیره سازی را به جلو می برد. او می‌گوید که مدل‌های استقرار برای محاسبات و ذخیره‌سازی باید به عنوان دستگاه‌های لبه، نزدیک، و IoT، چشم‌انداز زیرساخت‌های فناوری اطلاعات را تغییر دهند. مسائل بین صنعت، مانند امنیت داده ها و اثرات زیست محیطی/پایداری، نیز از عوامل اصلی تغییرات ذخیره سازی داده ها هستند.

آلن باکستون، مدیر بخش پزشکی قانونی در شرکت بازیابی اطلاعات Secure Data Recovery Services، می‌گوید چهار عامل متمایز در حال حاضر باعث تحول در فناوری ذخیره‌سازی می‌شوند: هزینه، ظرفیت، سرعت رابط، و چگالی. او توضیح می دهد که سازندگان هارد دیسک با کاهش زمان دسترسی و جستجو با سازندگان درایوهای حالت جامد (SSD) رقابت می کنند و در عین حال ظرفیت ذخیره سازی بالاتری را با هزینه کمتر ارائه می دهند. سازندگان حالت جامد از سرعت ورودی/خروجی بالاتر و توانایی اتخاذ سریع فاکتورهای شکل جدید خود خبر می دهند. باکستون خاطرنشان می کند، هر دو سازندگان SSD و هارد دیسک قابلیت اطمینان بهبود یافته را مطرح می کنند، اما هیچ برنده مشخصی در آزمایش های دنیای واقعی وجود ندارد.

زمان سرب در حال افزایش است، و صبر کم می شود. در اینجا چند راه برای مقابله با اختلال بی سابقه زنجیره تامین آورده شده است.
آیا در یافتن تجهیزات ضروری شبکه مشکل دارید؟ تو تنها نیستی. کمبود تجهیزات تقریباً در تمام دسته‌های شبکه و انواع دستگاه‌ها به سطوح رکوردی رسیده است. مارک آلن، مدیر خدمات مشاوره شبکه می‌گوید: «به نظر می‌رسد طولانی‌ترین زمان برای دستگاه‌های بزرگ‌تر و پیچیده‌تر، مانند مرکز داده و سوئیچ‌های هسته/توزیع، و دستگاه‌های لبه WAN بزرگ، از جمله روترها و تجهیزات SD-WAN باشد.» شرکت تحقیقاتی و مشاوره فناوری جهانی ISG.

کمبود تجهیزات شبکه

علت اصلی کمبود، تقاضای زیاد برای تراشه‌هایی است که تقریباً در همه انواع تجهیزات شبکه قرار می‌گیرند. کمبود این مؤلفه‌های حیاتی، ناشی از همه‌گیری کووید و تقاضای سرسام‌آور برای تجهیزات شبکه، شرکت‌ها را در سراسر جهان مجبور می‌کند تا برنامه‌های ارتقا و گسترش شبکه خود را کاهش دهند. جان آنند، مدیر تحقیقات زیرساخت و عملیات در شرکت تحلیل بازار فناوری اطلاعات، گروه تحقیقاتی Info-Tech، می‌گوید: همه کلاس‌های تجهیزات شبکه محدود هستند: پردیس، مرکز داده، LAN، مسیریابی و بی‌سیم.

شرکت تحقیقات بازار گارتنر در اواسط ژانویه گزارش داد که انتظار می رود کمبود تراشه در نیمه دوم سال 2022 کاهش یابد و درآمد جهانی نیمه هادی ها با رشد 9.4 درصدی در سال 2022 به 638.6 میلیارد دلار پیش بینی می شود. با کاهش کمبود تراشه ها و تثبیت قیمت ها، رشد آهسته تری در سال های 2023 و 2024 به دنبال خواهد داشت.

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

آسیب پذیرترین

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

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

راهبردهای مقابله ای

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

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

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

شبکه منطقه ذخیره‌سازی

چنین خوشه‌های شکستی معمولاً برای ذخیره‌سازی داده‌های مشترک به یک شبکه منطقه ذخیره‌سازی (SAN) متکی هستند. اما یک SAN مشترک خود یک نقطه شکست واحد را تشکیل می دهد که می تواند دسترسی بالا را به خطر بیندازد. اگر SAN از کار بیفتد، پایگاه داده SQL Server یا Oracle که از سیستم‌های مهم ماموریت شما پشتیبانی می‌کند، در دسترس نیست، و مهم نیست که چه تعداد گره در خوشه failover آماده تعامل با آن هستند.

برای سازمان‌هایی که ابر را برای یک محیط برنامه HA در نظر می‌گیرند، یک مشکل مهم‌تر وجود دارد: در حالی که برخی از فروشندگان ابر گزینه‌های ذخیره‌سازی مشترک را ارائه می‌دهند، همه گزینه‌ها 99.99٪ در دسترس بودن را تضمین نمی‌کنند.

آیا این بدان معناست که باید ابر را به عنوان گزینه ای برای محیط برنامه HA رها کنید؟ نه: این فقط به این معنی است که شما باید در مورد نحوه پیکربندی یک خوشه شکست مجدد فکر کنید.

درک دسترسی بالا در فضای ابری

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

اما اگر قراردادهای سطح سرویس (SLA) را از ارائه دهندگان اصلی ابر بخوانید، متوجه یک هشدار مهم خواهید شد: اگر خوشه HA خود را با ماشین های مجازی در چندین منطقه پیکربندی کنید، SLA ها تضمین می کنند که حداقل می توانید به آن دسترسی داشته باشید. حداقل 99.99 درصد مواقع یکی از آن گره هاست. این تضمین نمی کند که برنامه شما کاربردی باشد، فقط می توانید به یکی از VM ها دسترسی داشته باشید.

این یک تمایز مهم است که به مشکل SAN بازمی گردد: اگر برنامه های شما نتوانند به داده های شما دسترسی داشته باشند، مهم نیست که به چند ماشین مجازی دسترسی داشته باشید.

داده ها را به اشتراک بگذارید، نه فضای ذخیره سازی

این ما را به موضوع بازنگری در نحوه پیکربندی یک خوشه شکست در فضای ابری بازمی گرداند.

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

بهترین راه حل های سازمانی

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

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

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

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

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

محل کار در همه جا

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

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

آینده تجربه کاربری

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

همانطور که در گزارشی که توسط Deloitte و Gartner تهیه شده است، آمده است: “با قرار دادن کارگران در مرکز طراحی، ایجاد یک محل کار دیجیتالی امکان پذیر می شود که نحوه همکاری افراد، انجام کار و در نهایت انجام تجارت را تغییر می دهد.”

کسب و کارها چگونه می توانند این کار را انجام دهند؟

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

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

محیط تعاملی و انعطاف پذیر

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

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

SD-WAN به برخی از مشکلات MPLS پرداخته است، اما شرکت ها برای تحقق بخشیدن به پتانسیل کامل شبکه های SD-WAN در مقیاس بزرگ خود با مشکل مواجه شده اند. بنابراین در عوض به چه چیزی نیاز داریم؟ مدتی پیش، مقاله ای از وال استریت ژورنال را خواندم که گزارش می داد اکثر رانندگان جدید نمی دانند چگونه لاستیک را تعویض کنند، عمق آج را چک کنند یا لاستیک های خودروی خود را به درستی باد کنند. آنها این نکته را مسلم می‌دانند که چنین بخش مهمی از حمل‌ونقل آنها «فقط کار می‌کند»، گاهی اوقات با عواقب فاجعه‌باری که اتفاق می‌افتد. این باعث شد به مشکل مشابهی که امروز در فناوری اطلاعات داریم فکر کنم. اکثر مهندسان شبکه فراموش کرده اند که چگونه به درستی معماری، ساخت و نگهداری شبکه ها را انجام دهند. باور نمی کنی؟ من در یک دقیقه توضیح خواهم داد، اما اجازه دهید ابتدا در مورد چگونگی رسیدن به اینجا صحبت کنم.

MPLS پیچیدگی ساخت شبکه

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

سپس، در اوایل دهه 2000، سوئیچینگ برچسب چند پروتکلی (MPLS) وارد تصویر شد. چه تفاوتی! MPLS پیچیدگی ساخت شبکه ها را کاهش داد. MPLS با استفاده از برچسب‌ها برای مسیریابی، ساخت شبکه‌های سریع و قابل اعتماد را که به‌تازگی کار می‌کردند، بسیار آسان‌تر کرد و بسیاری از پیچیدگی‌ها از سازمانی به ارائه‌دهندگان خدمات منتقل شد. شرکت‌ها به‌تازگی به شبکه MPLS ارائه‌دهنده خود متصل شدند و بدون پیچیدگی ساخت و مدیریت شبکه‌های خصوصی خود، از خدمات قابل اعتماد، اگر نگوییم ارزان، برخوردار شدند. دیگر مورد نیاز نبود، بهترین معماران شبکه از شرکت نقل مکان کردند و به ساخت شبکه های پیچیده در ارائه دهندگان خدمات ادامه دادند. اکثر شرکت ها به سادگی این عضله معماری را به طور کامل از دست دادند. اما MPLS کامل نبود.

چرا MPLS جای خود را به SD-WAN داد

MPLS به طور فزاینده ای گران بود، به خصوص زمانی که با پهنای باند کالا مقایسه می شد. ارائه آن کند بود و عملاً هیچ دید یا کنترلی برای شرکت هایی که این سرویس را مصرف می کردند، نداشت. این به طور چشمگیری تلاش های ما برای بهینه سازی عملکرد و امنیت داخلی را با مشکل مواجه کرد. این فقدان دید، امنیت تنها به دلیل نامعلومی، و الزامات تدارکات بیش از حد پیچیده، فرصتی را برای یک تغییر انقلابی ایجاد کرد، و این زمانی بود که SD-WAN معرفی شد.

SD-WAN پاسخگو نیست

هنگامی که SD-WAN برای اولین بار در سال 2014 وارد صحنه شد، به نظر راه حلی بود که همه چیز را برطرف می کرد. MPLS خیلی گران است؟ SD-WAN می تواند از پهنای باند کالا برای ترافیک کمتر مهم استفاده کند و هزینه ها را کاهش دهد. MPLS کند است؟ SD-WAN با سرعت نرم افزار مستقر می شود. کنترل؟ شرکت‌ها دوباره مالک هواپیمای کنترل هستند و می‌توانند با چند کلیک ماوس شبکه‌ها را بخش‌بندی کنند، مهندسی ترافیک کنند و شبکه‌ها را بسازند و از بین ببرند. دید؟ خب، این مشکل همچنان پابرجا بود، اما جذابیت چابکی و مقرون به صرفه بودن برای ایجاد علاقه فوق العاده به SD-WAN و پذیرش سریع در سراسر شرکت کافی بود.

به جز اینکه SD-WAN به طور بهینه کار کند، به این معنی بود که به ساخت شبکه های خودمان بازگشته بودیم. برنامه ریزی زیرسازی، ساخت روکش ها، طراحی سیاست های مهندسی ترافیک. مطمئناً SD-WAN پیاده‌سازی را آسان کرد، اما طراحی شبکه به مهارت‌هایی نیاز داشت که مدت‌هاست در شرکت‌های معمولی از بین رفته بود. در نتیجه، شرکت ها برای تحقق بخشیدن به پتانسیل کامل شبکه های SD-WAN در مقیاس بزرگ خود با مشکل مواجه شده اند.

بدتر میشود. شبکه ها پیچیده تر و توزیع شده اند. شبکه‌های سازمانی با فاصله گرفتن از معماری‌های سنتی هاب و اسپیک شعبه‌های متعدد و مراکز داده کم، اکنون باید دفاتر، چندین ارائه‌دهنده ابر در مناطق مختلف، شبکه‌های لبه، کارگران راه دور و تعداد زیادی از دستگاه‌های اینترنت اشیا را به هم متصل کنند. و با SD-WAN، هر یک از آن ها نیاز به یک تونل دارد که باید طراحی و مدیریت شود. این بسیار دشوارتر است و به تخصص بسیار بیشتری نسبت به تامین شبکه های MPLS نیاز دارد.

بیشتر شرکت‌ها برای رعایت مهلت‌های مهاجرت ابری بیش از حد هزینه می‌کنند و در این فرآیند بدهی‌های فنی متحمل می‌شوند. تاثیر این موضوع چیست؟ در زندگی و شبکه، موارد بسیار کمی وجود دارد که همه در مورد آنها موافق باشند. آیا برنامه هایم را در محل اجرا می کنم یا در فضای ابری؟ آیا سیم کشی Cat5 یا Cat6 را نصب کنم؟ آیا از نرم افزار منبع باز یا تجاری استفاده می کنم؟ با این حال، تقریباً همه موافق هستند که رسیدگی به بدهی های فنی اولویت اصلی امسال است.

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

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

اولویت بندی آنچه به ابر می رود

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

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

بر اساس گزارش McKinsey & Company بر اساس نظرسنجی از 450 CIO و تصمیم گیرنده فناوری اطلاعات، متأسفانه، بسیاری از تلاش‌های مهاجرت ابری ناکارآمد و پرهزینه هستند. این گزارش نشان می‌دهد که گام‌های اشتباه بسیاری توسط کسب‌وکارها در مرحله مهاجرت ابری انجام می‌شود و هر گام اشتباهی عواقبی را به همراه دارد.

مک‌کینزی همچنین دریافت که ۷۵ درصد از کسب‌وکارها در مهاجرت ابری خود بیش از بودجه‌ای بودند. از منظر بدهی فنی شگفت‌انگیزتر، 63 درصد با تلاش‌های مهاجرت جلوتر از برنامه بودند.

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

برای رسیدگی به بدهی های فنی چه چیزی لازم است؟

دو رویکرد کلی برای کاهش بدهی فنی وجود دارد.

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

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

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

این سازمان‌ها 57 درصد بیشتر احتمال داشت کارکنانی با مجموعه مهارت‌های پیشرفته در زمینه‌هایی از جمله DevOps و FinOps استخدام کنند. آنها همچنین 32 درصد بیشتر احتمال داشت که حامیان مالی فعال مدیر عامل برای پروژه داشته باشند.

تارا بالاکریشنان، مدیر تعامل مک‌کینزی و شرکت، گفت: «در یک شرکت، مدیر عامل برای پذیرش ابر، راهبرد از بالا به پایین را تنظیم کرد و با کل شرکت در به‌روزرسانی‌های مکتوب و تالارهای شهر ارتباط برقرار کرد.» کارمندان می‌دانستند که استراتژی ابری از حمایت مستقیم مدیرعامل برخوردار است.»

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

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

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

1) اصول NetOps

اصول NetOps با آنچه در ابتدا به بسیاری از مدیران فناوری اطلاعات در مورد مدیریت شبکه آموزش داده شده بود، مغایرت دارد.

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

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

2) عدم آموزش ابزار NetOps

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

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

3) تمرکز بر معیارهای اشتباه

شاخص های کلیدی عملکرد (KPI) معیارهایی هستند که برای سنجش موفقیت یک هدف تجاری استفاده می شوند. KPIهای شبکه سنتی عمدتاً بر عملکرد و قابلیت اطمینان متمرکز هستند.

بدون تجزیه و تحلیل این نوع KPI ها، تشخیص اینکه آیا روش های NetOps موجود کار می کنند یا چه تنظیماتی باید انجام شوند، غیرممکن می شود.

4) عدم همکاری بین تیمی

NetOps صرفاً در مورد تغییر شیوه ها و فلسفه ها در خود تیم شبکه نیست. در عوض، این رویکرد از چندین سیلو بخش فناوری اطلاعات عبور می‌کند تا تیم‌های توسعه برنامه، سرور و نرم‌افزار را شامل شود. در حالی که چابکی شبکه برای این تیم‌های غیر شبکه‌محور با ارائه تغییرات سریع‌تر در پیکربندی شبکه که بسیار سریع‌تر از آنچه معمولاً انتظار می‌رفت، سود می‌برد، همکاری بین تیم‌ها یک ضرورت مطلق است.