https://virgool.io/feed/@p.yousefi97 Site Reliability Engineer@ArvanCloud fa 2026-06-16 20:59:25 https://files.virgool.io/upload/users/87780/avatar/JgmTyF.jpeg?height=120&width=120 https://virgool.io/@p.yousefi97 https://virgool.io/@p.yousefi97/dri-%D8%AE%D9%88%D8%A8-%D8%A8%D8%AF-%D8%B2%D8%B4%D8%AA-uxr5tlm4fupu مدل «مسوول مستقیم» (directly responsible individual-DRI) یک مفهوم مدیریته که شرکت‌هایی مثل اپل، گیت‌لب، فلیپ‌بورد از آن برای توزیع مسوولیت استفاده می‌کنند. در این مدل، برای هرکاری از بزرگ‌ترین حماسه(Epic) سازمان مثل تولید آیفون۱۳ گرفته تا کوچیک‌ترین کار مثل طراحی یک آیکون برای iMessage یک مسوول مستقیم مشخص می‌شه.در DRI همه چیز خیلی مشخص به یک فرد سپرده می‌شه از گردهم آوردن همکاران تا تهیه سخت‌افزار و موارد دیگه و به طبع مسوولیت موفقیت یا شکست کار هم به عهده این فرد قرار می‌گیره. این نقش می‌تونه مسوول یک حماسه، پروژه یا داستان، نگهداری یک سرویس یا برطرف کردن یک باگ باشه، به عنوان نمونه می‌شه به موارد زیر اشاره کرد:طراحی یک آیکون یا نگهداری زیرساخت تیکتینگجذب همکار جدیدرسیدن به Uptime 99.999 در سرویس Aدر واقع با تفکیکDRI به صورت مشخص می‌تونیم موضوع رو به افراد بسپاریم.مدل «مسوول مستقیم» یک مفهومه و نباید با فرآیند اشتباه گرفته بشه. هدف این مفهوم جلوگیری از گم شدن مسوولیته و باعث می‌شه اعضای شرکت به عنوان یک نقش در سازمان از مسوولیت‌های خودشون آگاه باشن و نسبت بهش دغدغه‌مند عمل کنند.در ساختار DRI ما با مشخص کردن یک نفر به عنوان «مسوول مستقیم» و سپردن کارها به اون جلوی «پخش مسوولیت»(Diffusion of responsibility) رو می‌گیریم و با ایجاد حس مسوولیت در یک نفر از پیشبرد کار اطمینان پیدا می‌کنیم. همچنین با مشخص شدن مسوولیت باعث افزایش تمرکز افراد می‌شیم.برای واضح‌تر شدن فرض کنید یک رخداد بوجود آمده و بخشی از سرویس از دسترس خارج شده، ممکنه چندین نفر در این موضوع درگیر باشن اما یک نفر به عنوان DRIاین رخداد مشخص می‌شه که اون فرد هم می‌تونه برای بقیه کارهای لازم DRI مشخصه کنه، به عنوان مثال مسوولیت اطلاع رسانی و سوشال رو به یک نفر محول کنه و یا مسوولیت یک تغییر یا تست رو به صورت مشخص به یک نفر دیگه بسپاره یا حتی مسوولیت پیگیری با یک وندور یا تامین کننده رو می‌شه به صورت مشخص واگذار کنه. ما با این کار می‌دونیم کی دقیقا قراره چه کاری انجام بده و هر فرد هم نقش خودش رو در این رخداد می‌دونه و تمرکز افراد نیز به حوزه مسوولیت خودشون محدود می‌شه.در تیم های توسعه هم به همین شکله، هر حماسه، داستان(Story) یا کار(Task) باید یک DRI مشخص داشته باشه و هر نقش در تیم از PM، PO، Team lead، Tech lead، Developer یک DRI واضح و شفاف دارد.«اعتماد» حلقه گم شدهانتخاب DRI در واقع یک فضای اعتماد ایجاد می‌کنه. اعتماد به آدم‌ها که بتوانند در حوزه مسوولیت خودشون کارها رو به نحو احسن انجام بدن و نیازی به میکرومنیج کردن کارها نباشه. این کار علاوه بر تفویض اختیار در حوزه تصمیم‌گیری باعث افزایش سرعت انجام کارها می‌شه، چون در کنارمون افرادی هستند که ما بهشون اعتماد داریم و اون‌ها می‌تونند مسوولانه در پیشبرد/نگهداری حوزه مسوولیتشون عمل کنند. نکته کلیدی در DRIفرصت کافی به فرد مسوول دادنه. یعنی ممکنه ما پیشبردی نبینیم ولی علت آن فراهم آوردن منابع یا مقدمات لازم باشه، در واقع اعتماد و عدم دخالت در حوزه DRI بخش خیلی مهمی از این کانسپت رو تشکیل می‌ده، تفویض اختیار به افراد به صورت سلسله مراتبی اتفاق می‌افته برای این‌که یک‌جور پیمان دوطرفه است. از سمت لیدر، فرد توانمند و مورد اعتماد انتخاب می‌شه و با شفافیت حوزه اختیار مسوولیت تفویض می‌شه و متقابلن فرد مسوول با آگاهی از توانایی خودش و انتظاری که از خروجی وجود داره این مسوولیت رو قبول می‌کنه و این پیمان که با آگاهی دو سمت شروع می‌شه اعتماد بیشتری ایجاد می‌کنه. مثل کسی که یک بسته رو به پیک می‌سپاره و برای به مقصد رسیدنش به پیک اعتماد می‌کنه لیدر به انجام رسوندن یک مسوولیت رو به شخصی می‌سپاره و برای به نتیجه رسیدنش به فرد اعتماد می‌کنه. هرجایی که این پیمان نقض بشه لیدر می‌تونه مسوولیت‌ها رو از فرد بگیره یا به شخص جدیدی منتقل کنه یا اگر فردی پذیرای مسوولیت موضوعی نیست بهتره براش بدنبال یک مالک جدید بگردیم. "افراد مسوول مستقیم" اجباری برای این‌که تایید دیگران در تصمیما‌تشون رو بگیرن ندارن و نیازی نیست از دیگران تایید بگیرن و نباید میکرومنیج بشن چون می‌تونه در تصمیم گیری براشون فشار ایجاد کنه. DRI باید کاملا آزاد و با در نظر گرفتن حلقه اعتماد در جهت انجام مسوولیتش تصمیم گیری کنه. از سمت دیگه مسوولیت تیم‌لید‌ها یا مسوولین سطح بالاتر سپردن مسوولیت به افراد با توانمندی و قابلیت‌های قابل دفاع هستش و حمایت از اون‌ها در توانمندتر شدن و به نتیجه رساندن مسوولیت‌ها.کشتی‌های بی ناخدابا سپری شدن زمان ممکنه یک سری موضوعات بدون DRI بوجود بیان که «مسوول مستقیم» مشخص نداشته باشن، معمولا این موارد روی میز می‌مونه و شاید حتی بهشون اشاره بشه اما به دلیل دغدغه به فراموشی سپرده بشن. برای همین لازمه تو بازه های زمانی DRI هامون رو بازبینی کنیم و اگر به موضوعی برخوردیم که DRI نداره سعی کنیم براش یک مسوول پیدا کنیم.تمرکز، تمرکز، تمرکزبا داشتنDRI ما با مشخص کردن مسوولیت‌ها جلوی عدم تمرکز تیم رو می‌گیریم، فرض کنید در یک تیم ۱۲ نفره نیاز نیست همه اعضا نگران چندین موضوع مختلف باشن و هر فرد بر روی موضوعات مربوط به خودش تمرکز داره.در این ساختار، تصمیم گیری رو به DRI ها واگذار می‌کنیم و ممکنه یک DRI مثل شخصی که مسوول یک حماسه است داستان‌ها رو به اشخاص دیگه‌ای بسپره و حتی اونایی که DRI یک داستان هستن برای تسک‌ها اشخاص دیگه‌ای رو به عنوان DRI مشخص کنن و این چرخه رو می‌شه ادامه دار دید اما موضوع مهم اینه که در این روند بتونیم به افراد اعتماد کنیم و هر فرد مسوول موفقت یا شکست مواردی هستش که تصمیمش رو به عهده داره.همچنین در مفهوم DRI تصمیم‌گیری‌ها به شکل خودکامه انجام می شن، ولی ما باید به خاطر داشته باشیم که مسوول موفقیت یا شکست تصمیم‌گیری هم ما هستیم و اگر چارچوبی برای موضوعی تعریف شده ما اون چارچوب رو باید رعایت کنیم. مثلن اگر برای پروداکشن شدن یک قطعه کد نیاز به Peer Review هست ما حتی اگر DRI باشیم نمی‌تونیم این مورد رو نقض کنیم و باید کدمون Reviewبشه. بهتره وقتی ما DRIموضوعی هستیم که می تونه بر روی افراد دیگه تاثیرگذار باشه در مورد تصمیمی که می‌خوایم بگیریم با افرادی که تحت تاثیر قرار می‌گیرن هم مشورت کنیم اما این موضوع پیچیدگی های خودشو داره، مثلن فرض کنید شخصی مسوول خرید خودکار در یک تیم باشه آیا چون قراره از این خودکار همه استفاده کنن باید نظر همه رو قبل از خرید کسب کنه؟ مشخصن نه! اما اگر خودکاری بخره که کسی نتونه استفاده کنه یا مقبول بقیه نباشه، تصمیمش با شکست مواجه شده. یا فرض کنیم من تیم لید یک تیم ۱۲ نفره باشم، آیا برای مثلا مهاجرت از Kanban به Scrum باید نظر همه رو جلب کنم؟ در اینجا هم مشخصا خیر! چون این مورد جزو DRI های تیم‌لید محسوب می‌شه و اونه که باید نسبت به عملکرد تیم و نحوه چرخش کارها و … دغدغه داشته باشه. اما باز هم می‌شه پرسید تصمیمی که با همراهی و مقبولیت همراه نباشه موفقیت آمیزه؟ احتمالا خیر. مثال ملموس دیگه ساعت دیلی تیم میتونه باشه، تیم لید می‌تونه ساعت دیلی رو مشخص کنه اما اگر این ساعت با همراهی اعضای تیم نباشه مشخصا یک تصمیم شکست خورده است. در واقع DRI به میزان زیادی به افراد اختیار می‌ده اما در مقابل پاسخگویی و مسوولیت‌پذیری هم انتظار داره. زمانی که ما DRI موضوعی هستیم مسوول خوشحال بودن بقیه نیستیم(البته برای مدیران و تیم‌لید‌ها متفاوته و حال خوب تیم بخشی از مسوولیت‌هاشون رو شامل می‌شه) اما باید به یاد داشته باشیم تصمیمی که روی بقیه افراد یا DRI ها تاثیر‌گذار باشه یا با همراهی نباشه معمولا موفقیت آمیز نیست.سیاهی بی انتهایکی از مواردی که باید در بحث DRI بهش توجه کنیم عدم ایجاد دایره تاریک در تصمیم گیری‌ها و موضوعاته، برای همین بخش مهمی از چرخه به تولید داکیومنت و شفافیت در تصمیم‌گیری‌ها بر می‌گرده ما همواره ازDRI هامون میخوایم دلیل تصمیم‌هاشون و یا مواردی که ما رو نسبت به موضوعی که مسوولش هستن آگاه کنن. با این کار ما زمینه رو برای Handover موضوعات و ایجاد زمینه برای دادن فیدبک در راستای ایجاد فضای گفت‌وگو فراهم می‌کنیم. وقتی DRI ها تصمیم‌هاشون رو شفاف بیان کنن هر کسی می‌تونه نسبت به تصمیم فیدبک بده و یک جورایی ما فضا رو برای مشارکت همه فراهم می‌کنیم اما تصمیم گیرنده در مورد موضوع شخص مسوول مستقیمه. ما افراد مسوول مستقیم رو همواره تشویق می‌کنیم که پذیرای نظرات و مشارکت بقیه افراد باشن.ما از DRI هامون انتظار داریم موارد زیر رو در خصوص موضوعاتی که DRI ش هستن داشته باشن:توجه به جزییات و کرنر کیس‌هامدیریت زمان و استرس یا فشار کاری مواردی که به عهده دارنپذیرای نظرات باشن و بتونن Collaboration داشته باشناگر حوزه مسوولیت بزرگی دارن مثل مدیریت یک تیم بتونن برای موضوعات DRI های مناسب پیدا کننبتونن مشکلات رو شناسایی کنن و قبل از فاجعه نسبت به رفع این مشکلات اقدام کنندر صورت شکست بتونن پاسخگو باشن و دوباره در راستای موفقیت قدم بردارن"شخص مسوول مستقیم" باید خود انگیخته (Self-starter) باشهتوجه داشته باشیم که درسته تصمیم گیرنده نهایی DRI هست ولی این نمی‌تونه جلوی نظر دادن بقیه و مشارکت بقیه رو بگیره، به عنوان مثال من میتونمDRI تسکی نباشم اما راهکاری براش ارایه بدم، اما این‌که این راهکار به مرحله عمل برسه رو "شخص مسوول مستقیم" اون تسک باید تصمیم گیری کنه.همچنین DRI ها می‌تونن برای تصمیم گیریشون تایید بقیه افراد رو هم بگیرن، فرض کنید من میخوام تصمیم بگیرم که ممکنه بارحقوقی داشته باشه و می‌تونم برای اطمینان تایید واحد حقوقی شرکت رو نسبت به تصمیمم بگیرم،‌ لازم به ذکر با این کار چیزی از مسوولیت من نسبت به موضوع کاهش پیدا نمی‌کنه.در انتها به نظرمDRI يک کانسپت خیلی خوب برای اطمینان از در جریان بودن کار‌ها و افزایش مشارکت و حس مسوولیت پذیری در افراد می‌تونه باشه که با توجه به سایز شرکت و تیم می‌شه ازش بهره‌ برد و خصوصا در دوران دورکاری میتونه به مدیریت تیم های Operation و توسعه کمک کنه.منابع:https://about.gitlab.com/handbook https://medium.com/@mmamet/directly-responsible-individuals-f5009f465da4https://www.forbes.com/sites/quora/2012/10/02/how-well-does-apples-directly-responsible-individual-dri-model-work-in-practice/?sh=1a90f9a2194c پارسا یوسفی پارسا یوسفی Tue, 02 Nov 2021 13:04:02 +0330 https://tech.arvancloud.ir/فیسبوک-as32934-ecnmrszhcgvi دیروز چه اتفاقی برای فیسبوک افتاد؟ خوب این سوالیه که خیلیا دارن از خودشون می‌پرسن و سعی می‌کنیم در اینجا تا حدودی به توضیحش بپردازیم.تمامی Public IP هایی که در دنیا وجود دارن زیر مجموعه یک Autonomous system number یا ASN میشن، ASN شماره‌ای ناهمتا است که توسط Regional Internet Registry (RIR) به Local Internet Registry(LIR) اختصاص داده میشه تا بتونن با اون عضوی از شبکه جهانی اینترنت بشن و میشه گفت اینترنت شبکه‌ای از شبکه‌هاست و هر شبکه برای حضور در اینترنت باید یک ASN داشته باشه.حالا برای ارتباط بین ASN ها در شبکه اینترنت از یک Routing Protocol استفاده میشه که به اون ‌BGP (Border Gateway Protocol) گفته میشه و وظیفه مسیریابی در دنیای اینترنت رو به عهده داره.میریم نگاهی بیندازیم که برای فیسبوک در این بخش چه اتفاقی افتاد.دیروز بخشی از سرویس‌های فیسبوک حوالی ساعت 15:39 UTC شروع به محو شدن کردن، درست شنیدین محو شدن!یعنی سرورها و منابعی که داشتن توسط 32394 ASN در اینترنت دیده می‌شد، از اینترنت ناپدیده شدن. همون‌طور که می‌تونید حدس بزنید Facebook ارتباط‌های BGP شو از دست داد و دیگه تو اینترنت دیده نمی‌شد.دلیل این اتفاق براساس اعلام رسمی خود فیسبوک به دلیل تغییر کانفیگ اشتباه در روترهای Backbone که وظیفه مسیریابی ترافیک رو بین دیتاسنترهای فیس‌بوک به عهده داشتن رخ داده. ما همچنان مشتاقانه منتظر اطلاعات بیشتری از سمت فیسبوک هستیم.ویدیو زیر از دسترس خارج شدن AS32934 رو نمایش میده. https://youtu.be/6awH_BCx_Mo با ناپدید شدن این ASN، یکی از مهمترین سرویس‌هایی که از دسترس خارج شد سرویس DNS بود و با از دسترس خارج شدن سرویس DNS عملا دیگه هیچ یک از دامنه‌های تحت مالکیت Facebook ریزالو نمی‌شدن.وقتی ما می‌خوایم به منابعی در شبکه اینترنت دسترسی داشته باشیم باید IP اون رو داشته باشیم پس برای رسیدن به یک صفحه وب یا حتی ارتباط اپلیکیشن‌های WhatsApp و Instagram که ما روی تلفن‌های همراه خودمون استفاده می‌کنیم بر اساس IP شکل می‌گیره، خوب پس DNS این جا چیکاره است؟خوب جوابش ساده است ما که نمی‌تونیم IPها رو بخاطر بسپاریم و تازه ممکنه IPها ثابت نباشن یا تغییر کنن، پس ما از سرویس DNS که یکی از وظایف اصلیش تبدیل اسم به IP استفاده می‌کنیم.سرویس DNS یک ساختار درختی داره که در بالا دامنه روت و سپس TLDها و بعد از اون Second level domain ها قرار می‌گیرن، به اسم‌هایی که در هر مرحله این درخت قرار می‌گیرن label گفته میشه و تعداد labelهای DNS نباید از 63 octet[1] فراتر بره.در مورد DNS Serverها هم می‌تونیم بگیم که به شکل کلی به چهار بخش زیر تقسیم می‌شن:سرورهای Root:‌ در دنیا ۱۳ سرویس‌دهنده دامنه root وجود داره که وظیفه اصلیشون راهنمایی Resolverها به سمت TLD هاست.سرورهای TLD: هر TLD برای نگهداری اطلاعات Second level domain دارای یکسری Nameserver و مدیریت TLD ها هم به وسیله IANA انجام میشه.سرورهای Authoritative: اطلاعات دامنه رو نگهداری می‌کنن مثلا در اینجا Facebook.com یک نمونه از Authoritative nameserver میشه نام برد.سرورهای Recursive Resolver: سرورهای DNSی که ما عموما روزمره ازشون استفاده می‌کنیم تو این دسته قرار می‌گیرند و وظیفه پاسخ‌دهی به درخواست‌های کاربران رو به عهده دارن، این سرورها خودشون برای به دست آوردن اطلاعات به سراغ Root و TLD و Authoritativeها میرن.از معروف‌ترین‌ اون‌ها میشه به 8.8.8.8 گوگل و 4.2.2.4 Level3 اشاره کرد.در عکس زیر سعی شده فرایند پاسخ‌دهی به یک درخواست DNS به شکل مختصر نشون داده بشه:وقتی Authoritative Nameserver از دسترس خارج می‌شه درخواست‌های Recursive Resolverها بی‌پاسخ می‌مونن و SERVfail به کلاینت نهایی نمایش داده میشه.یکی از ساید افکت‌های مهم این اتفاق افزایش درخواست‌ها به Recursive Resolverها بود، دلیل این اتفاق رو میشه به این شکل توضیح داد که خیلی از اپلیکیشن‌ها برای دسترسی به سرورهاشون دارن از DNS استفاده می‌کنن و وقتی که درخواست‌هاشون به مشکل می‌خوره دوباره تلاش می‌کنن و این چرخه همین‌طور ادامه داره.مثلا وقتی WhatsApp که رو موبایلمون داریم می‌خواد به سرور WhatsApp وصل بشه در ابتدا whatsapp.com رو می‌خواد تبدیل به IP کنه که این اتفاق با مشکل مواجه میشه پس دوباره تلاش می‌کنه و این تلاش‌های پی‌درپی سبب افزایش درخواست به Public Resolverهایی مثل Level3, Google, Cloudflare میشه و همین باعث شد سرویس‌های اونا هم با کندی و اختلالاتی همراه بشه.گراف زیر رو کلادفلر از افزایش درخواست‌های DNS مرتبط به Facebook منتشر کرده که به خوبی افزایش درخواست رو نمایش میده.بازگشتفیسبوک حوالی ساعت 21:00 UTC شروع به بازگشت سرویس‌هاش کرد و حدودا 21:20 UTC در دسترس قرار گرفت.امیدارم با توضیحات داده شده دلیل این قطعی سرویس های Facebook براتون مشخص شده باشه و با سازوکار بخشی از سرویس های تحت وب بیشتر آشنا شده باشید. پارسا یوسفی پارسا یوسفی Tue, 05 Oct 2021 16:46:45 +0330