حالت تاریک
فصل ۶ — جمعه، ۵ سپتامبر
در یکی دیگر از جلسات بیپایان وضعیت Phoenix، میفهمم توسعهدهندهها حتی بیشتر از آنچه میترسیدیم عقباند. همانطور که Wes پیشبینی کرده بود، کار بیشتر و بیشتری به انتشار بعدی موکول میشود، از جمله تقریباً همهٔ آزمونها.
یعنی ما باید مشکلات را پیدا کنیم وقتی در production منفجر میشوند، نه بخش Quality Assurance (QA).
عالی.
در یک فرصت آرام در بحث، به گوشیام نگاه میکنم و ایمیل Patty را میبینم. میخواهد دربارهٔ تخصیص منابع ملاقات کند و وعدهٔ شگفتیهای چشمگیر میدهد.
صفحهگستردهٔ پیوست را باز میکنم، سطح جزئیات امیدوارکنندهای میبینم، ولی روی صفحهٔ کوچک گوشی سر در نمیآورم. به Patty جواب میدهم که در راهم و از او میخواهم Wes هم آنجا ملاقات کند.
وقتی میرسم، متعجب میشوم Wes پروژکتور راه انداخته و صفحهگسترده را روی دیوار نشان میدهد. هیجانزدهام که برای تحلیل وضعیت جلسه میکنیم، نه فقط واکنش به آتشهای روزانه.
مینشینم. «خب، چی برایم دارید؟»
Wes شروع میکند. «Patty کار عالی کرد که این را جمع کرد. آنچه پیدا کردیم — خب، جالب بود.»
Patty توضیح میدهد: «مصاحبهها را انجام دادیم، داده جمع کردیم و تحلیل کردیم. الان این اعداد فقط برای منابع کلیدیمان است. از الان چیز نگرانکنندهای میبینیم.»
به یک ردیف در صفحهگسترده اشاره میکند. «اول، پروژههای زیادی داریم. Kirsten میگوید رسماً حدود سیوپنج پروژهٔ بزرگ کسبوکار را مدیریت میکند، که هر کدام تعهدی از ما دارند. در داخل عملیات IT، بیش از هفتاد پروژه شناسایی کردهایم و با هر مصاحبه این عدد بیشتر میشود.»
«صبر کن،» با تعجب واقعی میگویم و راست مینشینم. «صد و پنجاه نفر عملیات IT داریم، درست است؟ اگر از الان بیش از ۱۰۵ پروژه پیدا کردهاید، یعنی ۱.۵ نفر به ازای هر پروژه. زیاد به نظر نمیرسد؟»
Wes جواب میدهد: «کاملاً. و میدانیم تعداد پروژهها پایین است. پس تا آخر احتمالاً بیشتر شبیه یک نفر به ازای هر پروژه میشود. دیوانگی است.»
میپرسم: «این پروژههای داخلی چقدر بزرگاند؟»
Wes زبانهٔ صفحهگسترده را عوض میکند و فهرست پروژههایی که فهرست کردهاند را با تخمین نفر-هفته نشان میدهد: «Consolidate and upgrade e-mail server،» «Upgrade thirty-five instances of Oracle databases،» «Install supported Lemming database server،» «Virtualize and migrate primary business applications،» و غیره.
آه میکشم. بعضی پروژهها کوچکاند، ولی بیشترشان پروژههای بزرگ به نظر میرسند، تخمینزده سه نفر-سال یا بیشتر.
وقتی Patty حالت صورتم را میبیند، میگوید: «واکنش من هم همین بود. برای تعداد عظیم پروژه مسئولیم. پس بیایید ببینیم ظرفیت ما چقدر است. کمی سختتر است، چون نمیتوانیم آدم تصادفی به هر پروژه تخصیص دهیم.»
ادامه میدهد: «وقتی دیدیم چه کسی به هر پروژه تخصیص داده شده و تعهدها و دسترسپذیری دیگرشان چیست، این را پیدا کردیم.»
وقتی Wes زبانهٔ دیگر صفحهگسترده را ورق میزند، دلم میریزد.
«تاریک است، نه؟» Wes میگوید. «بیشتر منابع به Phoenix میرود. خط بعد را ببین: Compliance بزرگترین پروژهٔ بعدی است. حتی اگر فقط روی compliance کار کنیم، بیشتر منابع کلیدی را یک سال کامل مصرف میکند! Brent هم شامل است، راستی.»
با باور نکردن میگویم: «شوخی میکنی. اگر همهٔ پروژهها را متوقف کنیم جز یافتههای ممیزی، منابع کلیدی یک سال کامل مشغول میمانند؟»
«آره،» Patty سر تکان میدهد. «سخت است باور کنی، ولی فقط نشان میدهد چقدر کار در آن دسته یافتههای ممیزی است.»
به میز نگاه میکنم، بیحرف.
اگر کسی این اعداد را در اولین گفتوگویم با Steve نشان میداد، مثل پسرک فریاد میزدم و از اتاق میدویدم.
دیر نشده، فکر میکنم و به آن تصویر لبخند میزنم.
با آرامش تمرینشده میگویم: «خب، دانستن همیشه بهتر از ندانستن است. ادامه بدهید.»
Wes دوباره به صفحهگسترده نگاه میکند. «سومین مورد بزرگ حادثه و کار رفع خرابی است. الان احتمالاً هفتاد و پنج درصد وقت پرسنل را مصرف میکند. و چون اغلب سامانههای حیاتی کسبوکار را درگیر میکنند، حوادث بر همهچیز اولویت دارند، از جمله Phoenix و رفع یافتههای ممیزی.»
«راستی، میدانستی دیروز وقتی با Brent حرف میزدیم، مصاحبه را دو بار دوباره زمانبندی کردیم چون باید میرفت قطعی را رفع کند؟ پس ما داشتیم او را از کار Phoenix قطع میکردیم، فقط تا قطعی او را قطع کند!» میخندد.
من هم میخندم، ولی ناگهان قطع میکنم. «صبر کن. چه قطعی؟ چرا خبرم نکردی؟ نمیتوانیم سازمان را اینطور اداره کنیم!»
«خب، یک مسئلهٔ SAN دیگر بود، ولی چیز حیاتی نبود،» Wes جواب میدهد. «چند ماه پیش یک drive خراب شد، پس SAN بدون افزونگی کار میکرد. وقتی drive دیگر خراب شد، کل volume از کار افتاد. Brent کمک کرد بعضی databaseها را بازیابی کند وقتی SAN را بالا آوردیم.»
عصبانی فریاد میزنم: «لعنتی Wes. کاملاً قابل پیشگیری بود! یکی از تازهکارها را بگذار هر روز logها را برای خرابی drive چک کند. شاید حتی با چشم driveها را بازرسی کند و چراغهای چشمکزن را بشمارد. بهش نگهداری پیشگیرانه میگویند! Brent را برای Phoenix لازم داریم، نه برای کارهای بیاهمیت مثل این!»
Wes دفاعی میگوید: «هی، واقعاً کمی پیچیدهتر است. سفارش برای replacement drive گذاشتیم، ولی هفتهها در Procurement گیر کرد. مجبور شدیم vendor یکی را نسیه بدهد. تقصیر ما نبود.»
عصبانی میشوم. «Wes، گوش کن. مهم نیست! به Procurement اهمیت نمیدهم. مهم نیست vendorهای ناکارآمد چقدر مهربانند. میخواهم کارت را بکنی. مطمئن شو دوباره اتفاق نیفتد!»
نفس عمیق میکشم. میفهمم عصبانیت بهخاطر خرابی drive نیست، بلکه بهخاطر این است که پیوسته نمیتوانیم روی چیزهایی که برای شرکت مهمتریناند متمرکز بمانیم.
«ببین، فعلاً کنار بگذاریم،» به Wes نگاه میکنم. «ولی جدی میگویم کسی هر روز آن SAN را نگاه کند. هفتهٔ آینده جلسهای برای تو، من و Patty بگذار تا ریشهٔ این قطعیها را پیدا کنیم. باید بفهمیم چطور کار رفع خرابی را پایین بیاوریم تا کار پروژهای انجام شود. اگر کار Phoenix انجام نشود، شرکت در خطر است.»
«آره، فهمیدم. سعی میکنم قبل از راهاندازی Phoenix جا بدهد.» Wes با دلخوری سر تکان میدهد. «و امروز بعدازظهر سر SAN میروم.»
«خب، برگردیم به صفحهگسترده،» میگویم.
Patty غمگین مشاهده میکند: «درست میگویی. یک موضوع ثابت در مصاحبهها این بود که همه برای انجام کار پروژهای تلاش میکنند. حتی وقتی وقت دارند، برای اولویتبندی همهٔ تعهدها تلاش میکنند. مردم کسبوکار مدام از کارکنان ما میخواهند کاری برایشان بکنند. بهخصوص Marketing.»
«Sarah؟» میپرسم.
«البته، ولی فقط او نیست،» جواب میدهد. «عملاً هر مدیر ارشد شرکت گناهکار است که مستقیم به فرد IT مورد علاقهاش میرود، یا لطف میخواهد یا فشار میآورد کاری انجام شود.»
«چطور بازی را عوض کنیم و منابع بگیریم تا همهٔ این پروژهها درست انجام شوند؟» میپرسم. «از Steve چه بخواهیم؟»
Wes صفحهگسترده را پایین میکشد. «بر اساس اعداد تقریبی، احتمالاً باید هفت نفر استخدام کنیم: سه database administrator، دو server engineer، یک network engineer و یک virtualization engineer. البته میدانی پیدا کردن این آدمها وقت میبرد و بعد شش تا دوازده ماه دیگر تا کاملاً بهرهور شوند.»
البته میدانستم استخدامهای جدید فوراً بهرهور نیستند. ولی باز هم دلسردکننده بود بشنوم Wes میگوید کمک واقعی هنوز دور است، حتی اگر Steve headcount را تأیید کند.
بعداً همان روز، وقتی به دومین جلسهٔ CAB میروم، امیدوارم. اگر فرایند تغییر قدیمی را راه بیندازیم، شاید بتوانیم یکی از بزرگترین مسائل ممیزی را سریع حل کنیم و برد عملیاتی هم بگیریم.
از اینکه Patty و Wes اینقدر خوب با هم کار میکنند هم خوشحالم.
وقتی به اتاق کنفرانس نزدیک میشوم، صدای بلند دعوا میشنوم.
«—بعد Patty آن engineer را بهخاطر انجام کارش اخراج کرد. یکی از بهترین مهندسان شبکهٔ ما بود. تصمیم تو نبود!»
اشتباه نیست. Wes دارد فریاد میزند. بعد Patty با خشم جواب میدهد: «چی؟ تو روی اخراج تأیید کردی! چرا ناگهان تقصیر من است؟»
بعد John را میشنوم: «تصمیم درست بود. داریم وارد سال سوم یافتهٔ تکراری ممیزی حول کنترل تغییر میشویم. جلوی کمیتهٔ حسابرسی میرود. دفعهٔ بعد شاید فقط engineer اخراج نشود، اگر منظورم را فهمیدی.»
صبر کن. چه کسی John را به این جلسه دعوت کرده؟
قبل از اینکه John بدتر کند، سریع از در رد میشوم و با شادمانی میگویم: «عصر بخیر همه! آمادهاید چند change را بررسی کنیم؟»
چهارده نفر به من نگاه میکنند. بیشتر سرپرسهای فنی گروههای مختلف سر میز نشستهاند. Wes پشت صندلیاش ایستاده و دود از سرش بلند است، Patty جلوی اتاق با دستهای گرهخورده.
John عقب اتاق نشسته، دفترچهٔ سهحلقهای باز، کاملاً مهمان ناخوانده.
با هر دو دست لپتاپ عتیقهام را میگذارم. با صدای بلند به میز میخورد و باتری میافتد، چون نوار چسب دیگر جایش را نگه نمیدارد، و صدای خشخش میشنوم وقتی دیسک درایو در حال خاموششدن است.
حالت چهرهٔ عصبانی Wes لحظهای ناپدید میشود. «وای رئیس، تجهیزات عالی. Kaypro II است؟ سی سال است ندیدهام. بگو اگر floppy 8-inch برای بارگذاری CP/M لازم داری — یکی در انباری خانهام دارم.»
دو engineer زیر لب میخندند و اشاره میکنند. لحظهای به Wes لبخند میزنم، سپاسگزار از آرامش طنزآمیز.
همچنان ایستاده میگویم: «بگذارید بگویم چرا همهٔ شما را جمع کردم. با توجه به فوریت Phoenix، مطمئن باشید اگر فکر نمیکردم مهم است وقتتان را هدر نمیدادم.»
ادامه میدهم: «اول، حوادثی که به شکست SAN و حقوق سهشنبه منجر شد نباید دوباره تکرار شود. آنچه با یک شکست حقوق متوسط شروع شد به حادثهٔ آتش دوستانهٔ عظیم SAN تبدیل شد. چرا؟ چون با هم دربارهٔ تغییراتی که برنامهریزی یا اجرا میکنیم حرف نمیزنیم. قابل قبول نیست.»
«دوم، John درست میگوید. دیروز صبح با حسابرسانمان بودیم و انبوهی کمبود پیدا کردند،» ادامه میدهم. «Dick Landry از قبل از ترس لرزیده چون میتواند روی صورتهای مالی فصلی تأثیر بگذارد. باید کنترل تغییر را سفتتر کنیم، و بهعنوان مدیرها و سرپرسهای فنی باید بفهمیم چطور فرایند پایداری بسازیم که حوادث آتش دوستانه را جلوگیری کند و حسابرسان را از سرمان بردارد، در حالی که هنوز بتوانیم کار انجام دهیم. تا برنامهای برای رسیدن به آنجا نسازیم از این اتاق بیرون نمیرویم. فهمیدید؟»
وقتی مطمئن میشوم همه به اندازهٔ کافی ترسانده شدهاند، بحث را باز میکنم. «پس چه چیزی مانع رسیدن به آنجاست؟»
یکی از سرپرسهای فنی سریع میگوید: «من شروع میکنم. آن ابزار مدیریت تغییر غیرممکن است. میلیون field اجباری دارد و بیشتر وقتها drop-down boxهای 'applications affected' حتی چیزی که لازم دارم ندارند. برای همین دیگر change request نمیگذارم.»
سرپرس دیگر فریاد میزند: «دارد دروغ نمیگوید. برای رعایت قوانین Patty باید صدها server name را دستی در یک text box تایپ کنم. بیشتر وقتها جا کافی نیست! صد server name باید در text box شصتوچهار کاراکتری جا شود؟ چه احمقی آن form را ساخت؟»
دوباره خندهٔ بیرحمانه.
Patty سرخ است. فریاد میزند: «باید drop-down box استفاده کنیم تا یکپارچگی داده حفظ شود! دوست دارم application list را بهروز نگه دارم، ولی منبع ندارم. چه کسی application catalog و change management database را بهروز نگه میدارد؟ فکر میکنید جادویی خودش update میشود؟»
«فقط tool نیست Patty. کل فرایند خراب است،» Wes قاطع میگوید. «وقتی بچههایم change request میگذارند، باید عمرشان را برای تأیید صبر کنند، چه برسد به زمانبندی. کسبوکار روی گردنمان برای انجام کار فشار میآورد. نمیتوانیم منتظر تردید و مرددبودن بمانیم که form را درست پر نکردهایم.»
Patty تند جواب میدهد: «مزخرف است و میدانی. مردمت بهطور معمول قوانین را میشکنند. مثلاً وقتی همه change requestها را 'urgent' یا 'emergency change' علامت میزنند. آن field فقط برای حادثهٔ واقعی است!»
Wes پاسخ میدهد: «مجبوریم، چون علامتگذاری فوری تنها راه است تیم نگاه کند! چه کسی سه هفته برای تأیید صبر کند؟»
یکی از سرپرسهای مهندسی پیشنهاد میدهد: «شاید field دیگری بسازیم به نام 'extremely urgent؟'»
صبر میکنم تا هیاهو آرام شود. با این سرعت به جایی نمیرسیم. با خشم فکر میکنم و بالاخره میگویم: «ده دقیقه استراحت بگیریم.»
وقتی جلسه دوباره شروع میشود میگویم: «بدون فهرست changeهای مجاز و زمانبندیشده که در سی روز آینده اجرا میکنیم از این جلسه بیرون نمیرویم.»
«همانطور که میبینید، دستیار من تودهای کارت index خالی آورده. میخواهم هر گروه هر changeی که برنامهریزی میکند بنویسد، یک change در هر کارت. سه اطلاعات میخواهم: چه کسی change را برنامهریزی میکند، سامانهای که تغییر میکند، و خلاصهٔ یک جملهای.»
«تقویمی روی whiteboard کشیدهام که در نهایت changeهای تأییدشده را طبق زمانبندی اجرا میگذاریم،» ادامه میدهم. «این قوانین است. کوتاه و ساده.»
Wes یک بسته کارت برمیدارد و با تردید نگاه میکند. «واقعاً؟ کارت کاغذی، در این روزگار؟ چطور است از لپتاپ تو استفاده کنیم، که احتمالاً حتی از کاغذ هم قدیمیتر است؟»
همه میخندند، ولی Patty نه. عصبانی به نظر میرسد، آشکارا از جهتگیری راضی نیست.
«مثل هیچ فرایند مدیریت تغییری که دیدهام نیست،» John میگوید. «ولی changeهایم را روی board میگذارم، مثل firewall update و monitoring changeهای پیشرو برای چند روز آینده.»
شگفتآور، آمادگی John برای ورود بقیه را به حرکت وادار میکند و شروع میکنند changeهای برنامهریزیشدهشان را روی کارت بنویسند.
بالاخره Wes میگوید: «باش، امتحان کنیم. هر چیزی بهتر از آن ابزار مدیریت تغییر خراب است.»
یکی از سرپرسها مشتی کارت بالا میگیرد. «همهٔ database changeهایی که برنامه داریم تمام شد.»
وقتی سر تکان میدهم ادامه دهد، سریع یکی از کارتها را میخواند: «اجرای vendor-recommended database maintenance script روی Octave server XZ577 برای رفع مسائل performance POS فروشگاه retail. order entry database و applicationها را تحت تأثیر قرار میدهد. میخواهیم جمعهٔ آینده ساعت ۸:۳۰ شب انجام دهیم.»
سر تکان میدهم، از وضوح change پیشنهادی خوشحالم. ولی Wes میگوید:
«این change نیست! فقط اجرای یک database script است. اگر script را تغییر میدادید، چیزی برای حرف زدن داشتیم. بعدی.»
سرپرس سریع جواب میدهد: «نه، قطعاً change است. موقتاً بعضی database settingها را تغییر میکند، و نمیدانیم چه تأثیر productionی دارد. برای من به اندازهٔ database configuration change پرخطر است.»
change است یا نه؟ هر دو طرف استدلال را میبینم.
بعد از سی دقیقه بحث، هنوز روشن نیست تعریف 'change' چیست.
reboot کردن server change است؟ بله، چون نمیخواهیم کسی بیملاحظه server reboot کند، بهخصوص اگر سرویس حیاتی در حال اجراست.
خاموش کردن server؟ بله، به همان دلیل.
روشن کردن server؟ نه، همه فکر کردیم. یعنی تا وقتی کسی مثال duplicate DHCP server روشن کردن را آورد که کل enterprise network را بیستوچهار ساعت به هم ریخت.
نیم ساعت بعد بالاخره روی whiteboard مینویسیم: «'change' هر فعالیتی است فیزیکی، منطقی، یا مجازی روی applicationها، databaseها، operating systemها، networkها، یا hardware که میتواند روی سرویسهای ارائهشده تأثیر بگذارد.»
به ساعت نگاه میکنم، نگران که نزدیک نود دقیقه در اتاق بودهایم و هنوز اولین change را تأیید نکردهایم. فشار میآورم سریعتر برویم، ولی در پایان جلسهٔ دو ساعته فقط پنج change روی whiteboard نصب شده.
شگفتآور به نظر نمیرسد کسی جز من خسته باشد. همه با شور در بحث درگیرند، حتی Patty. همه ریسک changeهای پیشنهادی را بحث میکنند، حتی کشف میکنند یک change لازم نبود.
امیدوار میگویم: «دوشنبه ادامه میدهیم. همهٔ کارتها را هرچه زودتر به Patty بدهید. Patty، بهترین راه پردازش همهٔ کارتها چیست؟»
کوتاه میگوید: «امروز بعداً سبد میگذارم. فعلاً جلوی میز روی هم بگذارید.»
وقتی جلسه را تمام میکنیم، چند نفر در راه خروج میگویند: «جلسهٔ عالی،» «آرزو میکردم وقت بیشتری برای بحث change داشتیم،» «منتظر دوشنبهام.»
فقط Patty مانده، دستهای گرهخورده. «خون، عرق و اشک زیادی برای ساخت سیاست مدیریت تغییر قدیمی گذاشتیم، و همه باز هم نادیده گرفتند. چرا فکر میکنی این بار فرق میکند؟»
شانه بالا میاندازم. «نمیدانم. ولی تا سامانهای که کار کند ادامه میدهیم، و مطمئن میشوم همه کمک میکنند. فقط برای رفع یافتهٔ ممیزی نیست. راهی برای برنامهریزی، ارتباط و تغییر ایمن لازم داریم. تضمین میکنم اگر روش کارمان را عوض نکنیم، بهزودی از کار میافتیم.»
به سند سیاست قدیمی اشاره میکند: «نباید همهٔ این کار را دور بیندازیم. هفتهها طراحی کردیم و صدها هزار دلار با consultantها برای تغییر ابزارها خرج کردیم.»
کمی اشک در چشمش جمع میشود. یادم میافتد چقدر مدت تلاش کرده این فرایند را در سازمان جا بیندازد.
«میدانم کار خوب زیادی در همهٔ این فرایند گذاشته شده،» با همدردی میگویم. «ولی روبهرو شو. کسی واقعاً رعایت نمیکرد، همانطور که حسابرسان اشاره کردند. همچنین میدانیم مردم سامانه را دور میزدند، فقط میخواستند کارشان انجام شود.»
صادقانه میگویم: «شاید از نو شروع کنیم، ولی همهٔ تجربه و مهارت تو را برای بهکار انداختنش لازم داریم. هنوز فرایند توست، و میدانم برای موفقیت ما کاملاً حیاتی است.»
«باش،» با آهی تسلیمناپذیر میگوید. «فکر میکنم بیشتر از استفاده از فرایند قدیمی، بقا برایم مهمتر است.»
حالت چهرهاش عوض میشود. «چطور است خروجی جلسه و دستورالعملهای جدید ثبت درخواست تغییر را بنویسم؟»
بعدازظهر همان روز، در Phoenix war room هستم که Patty زنگ میزند. به راهرو میدوهم. «چی شده؟»
استرسزده به نظر میرسد. «مشکل داریم. فکر میکردم هفتهٔ آینده پنجاه change برای بررسی داریم. ولی الان ۲۴۳ change ثبت شده. مدام email میگیرم که میگویند آخر هفته کارت بیشتری انتظار داشته باش… فکر میکنم بیش از چهارصد change هفتهٔ آینده انجام میشود!»
لعنتی. چهارصد؟ چند تا از این چهارصد change پرخطر هستند، احتمالاً Phoenix، payroll application، یا بدتر را تحت تأثیر قرار میدهند؟
ناگهانه Rangemaster duty در Marines را به یاد میآورم. بهعنوان Rangemaster، مسئول ایمنی همه در firing range بودم. تصویر هولناکی از جمعیت چهارصد هجدهسالهٔ بینظارت از کامیون میپرند، به firing range میدوند، rifleها را به هوا شلیک میکنند، فریاد و هیاهو…
«اوم، حداقل مردم فرایند را رعایت میکنند،» با خندهٔ مضطرب میزنم.
صدای خندهٔ او را میشنوم. «با همهٔ change requestهای ورودی، چطور تا دوشنبه همه را مجاز کنیم؟ توقف موقت change بگذاریم تا همه تأیید شوند؟»
«قطعاً نه،» فوراً میگویم. «بهترین راه کشتن اشتیاق و حمایت همه این است که مانع شویم کاری که نیاز دارند انجام دهند. شک دارم فرصت دومی برای درست انجام دادنش بگیریم.»
«email بفرست به همه بگو هر change برای هفتهٔ آینده تا دوشنبه ثبت شود. changeهای دوشنبه نیاز به مجوز ندارند ولی changeهای بقیهٔ هفته نیاز دارند. بدون استثنا.»
صدای تایپ Patty روی phone را میشنوم. «فهمیدم. احتمالاً باید بعضی از افرادم آخر هفته کمک کنند کارتهای change را مرتب کنند. راستش از این همه change مبهوتام.»
من هم.
«عالی،» میگویم و نگرانیهایم را بیصدا میگذارم.