چهارشنبه‌شب است، شب پیش از تعطیلی آخر هفته، و فرم سفارش سایت از کار افتاده. مشتری‌ها خبر می‌دهند که مبلغ از حساب‌شان کسر شده، اما سفارشی ثبت نشده. مدیر فروش با تنها کسی تماس می‌گیرد که می‌داند سایت روی کدام سرور است و درگاه پرداخت با کدام کلید API به آن وصل شده: فریلنسری که سه سال پیش سایت را ساخت و از آن روز هر تغییری از دست او گذشته است. گوشی خاموش است؛ به روستایی رفته که آنتن ندارد. تا شنبه ظهر، کسب‌وکار در اوج فروش هفته تعطیل است؛ چون هیچ‌کس دیگری نمی‌داند از کجا باید شروع کند.
این یادداشت درباره‌ی سیستمی است که فقط یک نفر واقعاً می‌فهمد: سایتی که فقط یک توسعه‌دهنده می‌داند چطور deploy می‌شود، اتوماسیونی که منطقش را فقط یک کارشناس عملیات می‌داند، سروری که کسی جرئت نمی‌کند واردش شود، چون «آن cron job را فقط علی می‌شناسد». موضع ما صریح است: وابستگی به یک نفر مسئله‌ی آدم‌ها نیست؛ مسئله‌ی نبود سیستم است. هزینه‌اش هم همیشه در بدترین روز پرداخت می‌شود: روزی که آن نفر می‌رود، بیمار می‌شود، نرخش را دو برابر می‌کند یا هر تغییری هفته‌ها پشت در او می‌ماند.
مخاطب این متن دو تصویر آشناست: امیرحسین، صاحب کسب‌وکاری کوچک که سایت و اتوماسیون‌هایش را یک فریلنسر ساخته و هنوز هر مشکلی را با یک پیام به همان فریلنسر حل می‌کند؛ و سارا و رضا، مدیرانی در شرکتی رو به رشد که یک توسعه‌دهنده‌ی ارشد یا نیروی عملیات‌شان، بی‌آن‌که کسی تصمیمش را گرفته باشد، گلوگاه کل سازمان شده است. گرین‌لبز استودیوی تحویل محصول دیجیتال، اتوماسیون و هوش مصنوعی است و این الگو را بارها در آغاز همکاری‌ها دیده‌ایم.
مالکیت حساب‌ها یک چیز است، فهم سیستم چیزی دیگر
پیش‌تر در یادداشت دامنه و هاست به نام شما نیست؟ پس هنوز مالک سایت‌تان نیستید درباره‌ی مالکیت دارایی‌های دیجیتال نوشته‌ایم؛ این‌که دامنه، هاست و سورس‌کد به نام چه کسی است. حالا فرض کنید همه‌ی آن‌ها به نام شرکت است. آیا مسئله حل شده؟
نه لزوماً. داشتن کلید خانه با دانستن مسیر لوله‌ها یکی نیست. ممکن است به همه‌چیز دسترسی داشته باشید و باز نتوانید یک باگ ساده را رفع کنید، چون نمی‌دانید سایت چطور build می‌شود، کدام متغیر محیطی روی سرور تنظیم شده و اسکریپت پشتیبان‌گیری کجاست. مالکیت امری حقوقی است و فهم امری عملیاتی؛ بیشتر کسب‌وکارها حتی وقتی اولی را دارند، دومی را به یک نفر سپرده‌اند.
مهندسان نرم‌افزار برای این وضعیت اصطلاحی نیمه‌شوخی دارند: bus factor؛ یعنی چند نفر از تیم باید ناگهان از دسترس خارج شوند تا پروژه متوقف شود. اگر جواب «یک» است، شما سیستم ندارید؛ آدمی دارید که سیستم را در ذهنش نگه داشته است.
نشانه‌ها: این جمله‌ها را در شرکت‌تان می‌شنوید؟
وابستگی به یک نفر تقریباً هیچ‌وقت حاصل تصمیمی آگاهانه نیست؛ اتفاق می‌افتد، چون آن یک نفر سریع، باهوش و در دسترس بوده و سپردن کار به او ساده‌ترین راه بوده است. نشانه‌هایش آشناست:
- «باید از فلانی بپرسیم.» حتی عوض کردن متن یک دکمه در صف یک نفر می‌ماند.
- «به سرور دست نزنید، کار می‌کند.» کسی نمی‌داند دقیقاً چه چیزی روی سرور اجرا می‌شود، و به‌روزرسانی‌های امنیتی سال‌هاست معطل مانده‌اند.
- «آموزش نیروی جدید چند ماه طول می‌کشد.» توسعه‌دهنده‌ی تازه‌وارد هفته‌ها فقط سؤال می‌پرسد و جواب هر سؤال، باز در ذهن همان یک نفر است.
- «این اتوماسیون را مریم ساخته؛ فقط خودش می‌داند.» سناریوهای n8n یا Make، وب‌هوک‌ها و اتصال CRM به سامانه‌ی پیامک، بی‌هیچ نقشه‌ای کار می‌کنند؛ تا روزی که کار نکنند.
- «نمی‌دانیم این کلید API مال کدام سرویس است.» کلیدها در چت‌های تلگرام یا داخل کد پخش‌اند و کسی نمی‌داند عوض کردن هر کدام چه چیزی را می‌شکند.
هیچ‌کدام از این‌ها نشانه‌ی بد بودن آن یک نفر نیست. اغلب او آن‌قدر خوب بوده که سازمان هرگز لازم ندیده چیزی را بیرون از ذهنش ثبت کند.
چرا این مسئله‌ی آدم‌ها نیست
مدیران وقتی به این وابستگی پی می‌برند، یا از آن یک نفر دلخور می‌شوند، گویی عمداً دانش را احتکار کرده است؛ یا تصمیم می‌گیرند نفر دیگری استخدام کنند تا «پشتیبان» باشد. هر دو واکنش، تشخیص غلط‌اند.
بیشتر کسانی که به نقطه‌ی تکی شکست سازمان تبدیل شده‌اند، هیچ نقشه‌ای برای انحصار نداشته‌اند. فقط هیچ‌کس از آن‌ها نخواسته کارشان را قابل انتقال کنند و هیچ‌کس آن را بخشی از تعریف «کار تمام‌شده» ندانسته است. وقتی تنها معیار موفقیت این است که سیستم «کار کند»، کسی برای «قابل فهم بودن» وقت نمی‌گذارد. سازمانی که فقط خروجی را می‌بیند، به وابستگی پاداش می‌دهد.
استخدام نفر دوم هم به‌تنهایی دردی دوا نمی‌کند. اگر مسیری برای انتقال دانش نباشد، نفر دوم یا ماه‌ها منتظر وقت آزاد نفر اول می‌ماند، یا بخش تازه‌ای می‌سازد که این بار فقط خودش می‌فهمد. حالا به‌جای یک جزیره، دو جزیره دارید. این الگو را در یادداشت فرآیند خراب را استخدام درمان نمی‌کند با جزئیات بیشتری کاویده‌ایم.
هزینه‌هایی که تا روز رفتن آن یک نفر دیده نمی‌شوند
سرعت و مقیاس
وقتی هر تغییری از یک گلوگاه عبور می‌کند، سرعت کل سازمان برابر است با ظرفیت خالی آن یک نفر. کمپین منتظر یک صفحه‌ی فرود می‌ماند و تیم فروش منتظر یک فیلد تازه در CRM. بزرگ کردن تیم هم کمکی نمی‌کند: هر نیروی تازه به‌جای افزودن ظرفیت، از وقت همان یک نفر کم می‌کند.
قدرت چانه‌زنی
فریلنسری که می‌داند هیچ‌کس دیگر سیستم را نمی‌فهمد، لازم نیست آدم بدی باشد تا نرخش را بالا ببرد؛ کافی است منطق بازار را بشناسد. بسیاری از مدیران دقیقاً روزی به این وابستگی پی می‌برند که پیام «از ماه آینده نرخ من دو برابر می‌شود» می‌رسد.
ریسک
بیماری، مهاجرت، استعفا یا اختلاف کاری؛ هر کدام می‌تواند کسب‌وکار را هفته‌ها فلج کند، و این ریسک تا روز وقوعش در هیچ گزارشی دیده نمی‌شود.
ارزش کسب‌وکار
شریک تازه، سرمایه‌گذار یا خریدار کسب‌وکار، زود می‌پرسد: «اگر فلانی برود، چه می‌شود؟» سیستمی که فقط یک نفر می‌فهمد، از چشم خریدار یا سرمایه‌گذار دارایی نیست، بدهی است.
چرا «مستند کنید» به‌تنهایی جواب نمی‌دهد
توصیه‌ی همیشگی این است: «بگویید همه‌چیز را مستند کند.» نتیجه معمولاً فایل ورد بلندی است که هفته‌ی آخر نوشته شده و شش ماه بعد، نیمی از آن دیگر درست نیست.
مستندات فاسد می‌شوند؛ این طبیعت آن‌هاست. سندی که بخشی از کار روزمره نیست و صاحبی ندارد، از همان روز نوشتنش رو به کهنگی می‌رود. پس پرسش درست این نیست که «سند داریم یا نه؟». پرسش درست این است: آیا کسی غیر از آن یک نفر، واقعاً این کار را انجام داده است؟
آنچه واقعاً کار می‌کند
چند عادت و ابزار ساده، دانش را از ذهن افراد به خود سیستم منتقل می‌کند. هیچ‌کدام گران نیست؛ فقط باید عمداً انجام شود.
runbook برای کارهای تکراری و بحرانی
runbook سندی کوتاه و عملیاتی است که گام‌به‌گام می‌گوید چطور deploy کنیم، اگر سایت از دسترس خارج شد اول کجا را ببینیم و چطور از پشتیبان بازیابی کنیم؛ برای لحظه‌ی بحران نوشته می‌شود، نه برای روایت تاریخچه. تیم SRE گوگل در کتاب مهندسی قابلیت اطمینان سایت می‌نویسد که ثبت بهترین رویه‌ها از پیش، در قالب playbook، زمان بازیابی از حادثه را نسبت به بداهه‌کاری تقریباً سه برابر بهبود می‌دهد.
کد در repo متعلق به شرکت
هر خط کدی که سیستم شما را می‌چرخاند، از قالب سایت تا اسکریپت کوچکی که هر شب گزارش فروش را ایمیل می‌کند، باید در repo متعلق به شرکت باشد؛ نه در لپ‌تاپ فریلنسر و نه فقط روی خود سرور. اسکریپتی که تنها روی سرور زندگی می‌کند، با همان سرور از دست می‌رود.
deploy خودکار، یا دست‌کم اسکریپت‌شده
اگر deploy مجموعه‌ای از ده کار دستی است که فقط یک نفر ترتیبش را می‌داند، دانش در ذهن اوست. اگر یک اسکریپت یا pipeline است، دانش در خود سیستم است. زیرساخت هم همین‌طور: تنظیمات سرور و DNS هرچه بیشتر به شکل کد (infra-as-code) ثبت شوند، کمتر به حافظه‌ی یک نفر وابسته‌اند.
نفر دومی که واقعاً deploy کرده است
این مهم‌ترین بند فهرست است. سند و اسکریپت تا وقتی کسی دیگر با آن‌ها کار نکرده، فقط ادعا هستند. نفر دوم باید دست‌کم یک بار، در شرایط عادی و بدون کمک نفر اول، یک تغییر واقعی را از ابتدا تا انتها منتشر کند. هر جا گیر کرد، شکاف سیستم همان‌جاست.
دفتر تصمیم، به سبک ADR
بخش بزرگی از دانشی که با رفتن یک نفر می‌رود، «چه» نیست، «چرا»ست. چرا این پایگاه داده را انتخاب کردیم؟ چرا پرداخت از این سرویس می‌گذرد؟ چرا آن ماژول قدیمی هنوز حذف نشده؟ Architecture Decision Record یا ADR، قالبی ساده برای ثبت همین تصمیم‌هاست: زمینه، تصمیم، پیامدها. یک فایل متنی در همان repo، با چند سطر برای هر تصمیم مهم، کفایت می‌کند.
ماتریس دسترسی
جدولی ساده که بگوید مالک هر سیستم کیست، جایگزینش کیست و کلیدهایش کجاست:
| سیستم | مالک اصلی | نفر جایگزین | محل نگهداری کلیدها | آخرین آزمایش بازیابی |
|---|---|---|---|---|
| سایت و فروشگاه | توسعه‌دهنده‌ی بیرونی | مدیر محصول | مدیر رمز سازمانی | خرداد ۱۴۰۵ |
| CRM و اتوماسیون پیامک | کارشناس عملیات | مدیر فروش | مدیر رمز سازمانی | هنوز انجام نشده |
| سرور و پشتیبان‌گیری | توسعه‌دهنده‌ی ارشد | تیم پشتیبانی بیرونی | مدیر رمز سازمانی | مهر ۱۴۰۵ |
ستون آخر عمداً آن‌جاست. پشتیبان‌گیری‌ای که بازیابی‌اش هرگز آزموده نشده، فقط امید است.
چک‌لیست تحویل
هر بار که کسی نقش یا همکاری را ترک می‌کند، یا پروژه‌ای «تمام» می‌شود، یک چک‌لیست تحویل استاندارد باید پر شود: repo، دسترسی‌ها، runbookها، کارهای زمان‌بندی‌شده و cron jobها، سرویس‌های بیرونی و کلیدهای API، و دست‌کم یک جلسه‌ی deploy مشترک. وگرنه به همان وضعیتی می‌رسید که در یادداشت پروژه‌ات «تمام» شده؛ پس چرا هنوز کسی جوابگو نیست؟ توصیفش کرده‌ایم.
آزمون پنج‌پرسشی
درباره‌ی مهم‌ترین سیستم کسب‌وکارتان صادقانه جواب بدهید:
- اگر آن یک نفر دو هفته کاملاً در دسترس نباشد، می‌توانیم یک باگ فوری را رفع و منتشر کنیم؟
- آیا کسی غیر از او، در سه ماه گذشته دست‌کم یک بار deploy کرده است؟
- آیا همه‌ی کد، از جمله اسکریپت‌ها و cron jobها، در repo شرکت است و نسخه‌ی روی سرور با آن یکی است؟
- آیا فهرستی داریم که بگوید هر کلید API به کدام سرویس وصل است و اگر باطل شود، چه چیزی از کار می‌افتد؟
- آیا توسعه‌دهنده‌ی تازه می‌تواند در کمتر از دو هفته، بی‌آن‌که نیمی از وقت نفر اول را بگیرد، نخستین تغییر واقعی‌اش را منتشر کند؟
اگر جواب دو پرسش یا بیشتر «نه» یا «مطمئن نیستم» است، bus factor سیستم شما به احتمال زیاد یک است.
برنامه‌ی ۳۰، ۶۰ و ۹۰ روزه؛ بدون اخراج و بدون بازنویسی
وسوسه‌ی رایج، بازنویسی کل سیستم یا کنار گذاشتن آن یک نفر است. هر دو ریسک را بیشتر می‌کنند: بازنویسی ماه‌ها طول می‌کشد و در تمام آن مدت هنوز به همان نفر وابسته‌اید؛ کنار گذاشتنش هم یعنی جلو انداختن روز بحران. مسیر درست، آرام و مرحله‌ای است و آن یک نفر را نه متهم، که صاحب پروژه‌ی انتقال دانش می‌کند.
۳۰ روز نخست: نقشه
- فهرست همه‌ی سیستم‌ها، سرورها، سرویس‌های بیرونی، اتوماسیون‌ها و کلیدهای API را دربیاورید.
- همه‌ی کد و اسکریپت‌ها را به repo شرکت منتقل کنید.
- کلیدها و رمزها را از چت‌ها و فایل‌های پراکنده به یک مدیر رمز سازمانی ببرید.
- با آن یک نفر صریح حرف بزنید: هدف کاستن از ریسک کسب‌وکار است، نه کاستن از نقش او. بخشی از وقتش را رسماً به این کار اختصاص دهید و بابتش پول بدهید.
روز ۳۱ تا ۶۰: انتقال
- برای سه کار حیاتی، یعنی deploy، بازیابی از پشتیبان و رفع رایج‌ترین خطا، runbook بنویسید.
- نفر دوم را انتخاب کنید تا با همراهی نفر اول، دو یا سه deploy واقعی انجام دهد.
- تصمیم‌های مهم معماری را در چند ADR کوتاه ثبت کنید.
روز ۶۱ تا ۹۰: آزمایش
- یک «روز غیبت» برگزار کنید: نفر اول یک روز کاملاً در دسترس نیست و نفر دوم تغییری واقعی را منتشر می‌کند. هر گره، یک اصلاح در runbook است.
- یک بازیابی کامل از پشتیبان را در محیط آزمایشی تمرین کنید.
- چک‌لیست تحویل را بخشی ثابت از هر پروژه و هر قرارداد کنید تا وابستگی تازه از نو شکل نگیرد.
برای امیرحسین: لازم نیست با فریلنسرتان قطع همکاری کنید
اگر صاحب کسب‌وکاری کوچک هستید و همه‌چیز را یک فریلنسر ساخته، راه‌حل جنگیدن با او نیست. در تمدید بعدی همکاری، تحویل repo، چند runbook کوتاه و یک جلسه‌ی deploy مشترک با یک نفر دیگر را جزو تعهدات بنویسید و هزینه‌اش را هم بپردازید. فریلنسر حرفه‌ای از این درخواست استقبال می‌کند. اگر با مقاومت جدی روبه‌رو شدید، همان مقاومت مهم‌ترین داده برای تصمیم بعدی شماست.
برای سارا و رضا: قهرمان‌سازی را متوقف کنید
در شرکت رو به رشد، نقطه‌ی تکی شکست معمولاً محبوب‌ترین آدم تیم است: توسعه‌دهنده‌ی ارشدی که نیمه‌شب سرور را نجات می‌دهد. سازمان تشویقش می‌کند و ناخواسته وابستگی را محکم‌تر می‌کند.
bus factor سیستم‌های کلیدی را به یکی از شاخص‌های مرور فصلی تیم فنی تبدیل کنید. از توسعه‌دهنده‌ی ارشد بخواهید کمتر انجام دهد و بیشتر بازبینی کند. نوبت پاسخ‌گویی به حادثه‌ها را بچرخانید و انتقال دانش را در ارزیابی عملکرد پاداش بدهید. ارشد واقعی کسی است که سیستم بدون او هم کار کند، نه کسی که سیستم بدون او متوقف شود.
گرین‌لبز کجای این تصویر است
ما در گرین‌لبز محصول دیجیتال، اتوماسیون و راهکارهای هوش مصنوعی می‌سازیم و تحویل می‌دهیم. اما «تحویل» برای ما یعنی چیزی بیش از سیستمی که کار می‌کند: کد در repo متعلق به خود شما، runbook برای کارهای حیاتی، ثبت تصمیم‌های مهم، و جلسه‌ی تحویلی که در آن نیروی خود شما یک deploy واقعی انجام می‌دهد. معیار ما ساده است؛ اگر فردا همکاری‌مان تمام شود، سیستم شما نباید یتیم شود.
اگر حس می‌کنید یکی از سیستم‌های کسب‌وکارتان فقط در ذهن یک نفر زندگی می‌کند، تیم گرین‌لبز می‌تواند در یک جلسه‌ی کوتاه نقشه‌ی این وابستگی‌ها را با شما مرور کند. از صفحه‌ی خدمات گرین‌لبز شروع کنید.
پرسش‌های رایج
آیا این یعنی به توسعه‌دهنده‌مان اعتماد نکنیم؟ نه. این بحث درباره‌ی اعتماد نیست، درباره‌ی ریسک است. قابل‌اعتمادترین آدم‌ها هم بیمار می‌شوند یا شغل عوض می‌کنند. سیستمی که به یک نفر وابسته نباشد، به نفع خود او هم هست؛ دیگر لازم نیست در مرخصی گوشی‌اش روشن بماند.
تیم ما فقط یک توسعه‌دهنده دارد. نفر دوم را از کجا بیاوریم؟ لازم نیست تمام‌وقت باشد؛ کارمندی فنی‌تر در خود شرکت یا شریکی بیرونی با قراردادی کوچک کافی است، به شرط آن‌که چند بار در سال deploy و بازیابی را واقعاً تمرین کند.
ابزارهای هوش مصنوعی نمی‌توانند جای آن یک نفر را بگیرند؟ می‌توانند در خواندن کد و نوشتن پیش‌نویس مستندات کمک بزرگی باشند. اما نمی‌دانند چرا فلان تصمیم گرفته شد یا کدام سرویس بیرونی را کسی ماه‌ها پیش دستی تنظیم کرده است. این دانش را باید از ذهن آدم‌ها بیرون کشید.
جمع‌بندی
سیستمی که فقط یک نفر می‌فهمد، تا وقتی آن یک نفر هست، بی‌نقص به نظر می‌رسد. هزینه‌اش جایی ثبت نمی‌شود، تا آن چهارشنبه‌شبی که گوشی خاموش است، تا آن پیامی که نرخ تازه را اعلام می‌کند، یا تا آن جلسه‌ی سرمایه‌گذاری که کسی می‌پرسد «اگر او برود چه می‌شود؟».
راه‌حل نه بدگمانی به آدم‌هاست، نه استخدام عجولانه و نه بازنویسی پرهزینه؛ انتقال آگاهانه‌ی دانش از ذهن افراد به سیستم است، تا جایی که نفر دوم بتواند واقعاً deploy کند. سازمانی که این کار را بکند، آدم‌های خوبش را از دست نمی‌دهد؛ فقط دیگر گروگان هیچ‌کس نیست.
