واقعیت یک مهندس شبکه (با رشته و ... نمک؟)
اخیراً هنگام بحث در مورد حوادث مختلف با مهندسان، متوجه الگوی جالبی شدم.
در این بحث‌ها، مسئله «علت ریشه‌ای» همواره مطرح می‌شود. خوانندگان وفادار احتمالاً می دانند که من دارم بر . در بسیاری از سازمان ها، تجزیه و تحلیل حوادث کاملاً بر اساس این مفهوم است. آنها از تکنیک های مختلفی برای شناسایی روابط علت و معلولی استفاده می کنند، مانند . این روش ها به اصطلاح «خطی بودن رویدادها» را به عنوان یک جزم غیر قابل انکار فرض می کنند.
وقتی این ایده را به چالش می کشید و به این نکته اشاره می کنید که خطی بودن در سیستم های پیچیده به طرز اطمینان بخشی فریبنده است، بحث جذابی ایجاد می شود. مخالفان مشتاقانه اصرار دارند که فقط آگاهی از "علت اصلی" به ما امکان می دهد آنچه را که اتفاق می افتد درک کنیم.
من متوجه یک الگوی جالب شدم: توسعه دهندگان و توسعه دهندگان به این ایده واکنش متفاوتی نشان می دهند. در تجربه من، توسعه دهندگان بیشتر استدلال می کنند که علت اصلی مهم است و روابط علت و معلولی همیشه می تواند در رویدادها ایجاد شود. از سوی دیگر، DevOps اغلب موافق هستند که یک دنیای پیچیده همیشه از خطی بودن پیروی نمی کند.
همیشه فکر می کردم چرا اینطوری شده؟ چی می سازد برنامه نویسان برای انتقاد از ایده "علت اصلی یک افسانه است" مانند آن؟ مانند سیستم ایمنی که عامل خارجی را می شناسد. چرا آنها این گونه واکنش نشان می دهند، در حالی که توسعه دهندگان نسبتاً تمایل دارد این ایده را در نظر بگیرید؟
من کاملاً مطمئن نیستم، اما در این مورد نظراتی دارم. این به زمینه های مختلفی مربوط می شود که این متخصصان کار روزانه خود را در آن انجام می دهند.
توسعه دهندگان اغلب با ابزارهای قطعی کار می کنند. البته، کامپایلرها، لینک‌کننده‌ها، سیستم‌های عامل - همه اینها سیستم‌های پیچیده‌ای هستند، اما ما به این واقعیت عادت کرده‌ایم که نتیجه قطعی می‌دهند و آنها را قطعی تصور می‌کنیم: اگر همان داده‌های ورودی را ارائه کنیم، معمولاً انتظار داریم که همان خروجی از این سیستم ها و اگر مشکلی در خروجی ("اشکال") وجود داشته باشد، توسعه دهندگان آن را با تجزیه و تحلیل داده های ورودی (از کاربر یا مجموعه ای از ابزارها در طول فرآیند توسعه) حل می کنند. آنها به دنبال "خطا" می گردند و سپس داده های ورودی را تغییر می دهند. این "اشکال" را برطرف می کند.
فرض اساسی توسعه نرم افزار: همان داده ورودی به طور قابل اعتماد و قطعی خروجی یکسانی را تولید می کند.
در واقع، یک نتیجه غیر قطعی به خودی خود یک اشکال در نظر گرفته می‌شود: اگر خروجی غیرمنتظره یا اشتباه بازتولید نشود، توسعه‌دهندگان تمایل دارند تحقیقات را به سایر بخش‌های پشته (سیستم عامل، شبکه، و غیره) گسترش دهند که همچنین رفتار می‌کنند. کم و بیش قطعی، تولید یک نتیجه با همان داده های ورودی... و اگر اینطور نیست، پس این هنوز یک اشکال در نظر گرفته می شود. اکنون یک باگ سیستم عامل یا شبکه است.
در هر صورت، جبرگرایی یک فرض اساسی و تقریباً بدیهی برای اکثر برنامه‌نویسان است.
اما برای هر فرد توسعه‌دهنده‌ای که روز خود را صرف افزایش سخت‌افزار یا کشف یک API ابری کرده است، ایده یک دنیای کاملاً قطعی (تا زمانی که حتی امکان نقشه‌برداری از همه ورودی‌ها وجود داشته باشد!) در بهترین حالت یک مفهوم زودگذر است. حتی اگر آن را کنار بگذارید ، مهندسان با تجربه عجیب ترین چیزها را در این دنیا دیده اند. آنها این را می دانند بدون ذکر میلیون ها عامل دیگر در محیط.
بنابراین برای مهندسان با تجربه آسان تر است که شک کنند که همه حوادث یک علت ریشه ای دارند و تکنیک هایی مانند "پنج چرا" به درستی (و به طور تکراری!) به آن علت اصلی منجر می شود. در واقع، این در تضاد با تجربه خود آنها است، جایی که قطعات پازل در عمل چندان منظم نیستند. بنابراین آنها این ایده را راحتتر می پذیرند.
البته، من نمی گویم که توسعه دهندگان ساده لوح، احمق هستند یا نمی توانند درک کنند که خطی بودن چگونه می تواند فریبنده باشد.
اما به نظر من واکنش رایج توسعه دهندگان در این بحث ها اغلب به این واقعیت مربوط می شود که مفهوم جبرگرایی در کل به خوبی به آنها خدمت می کند در کارهای روزمره آن‌قدر که مهندسان مجبورند گربه‌های شرودینگر را در زیرساخت‌هایشان بگیرند، با عدم جبر مواجه نمی‌شوند.
این ممکن است به طور کامل واکنش‌های توسعه‌دهنده مشاهده‌شده را توضیح ندهد، اما یادآوری قدرتمندی است که واکنش‌های ما ترکیبی پیچیده از عوامل بسیاری است.
مهم است که این پیچیدگی را به خاطر بسپاریم، چه با یک حادثه مواجه باشیم، چه با همکاری در یک خط لوله تحویل نرم افزار، یا تلاش برای درک جهان گسترده تر.
منبع: www.habr.com