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

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

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

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

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

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

عدم محدودیت در انتخاب زبان

برنامه‌نویس‌های گوگل از چه زبانی استفاده می‌کنند؟ این را می‌توان یکی از پرتکرارترین سوالاتی دانست که از ایرانی‌های حاضر در گوگل پرسیده می‌شود.

آن طور که ‏مختاریان می‌گوید راهنما و گایدلاینی برای انتخاب زبان وجود نداشته و مسئله کارکنان این شرکت نیست:

«اکثر سرویس‌های قدیمی گوگل با زبان C++ نوشته شده بودند. اما طی سال‌ها اخیر بیشتر از GO استفاده می‌شود. اما مهم این است که اعضای تیم روی چه زبانی تسلط دارند و این زبان تا دو سه سال آینده چه سرنوشتی خواهد داشت. تقریبا مشخص است هر زبان برای چه زمینه‌ای کاربرد دارد از همین روی همه چی به انتخاب تیم بوده که با چه زبانی راحت‌ترند. اگرچه برخی از زبان‌ها نیز تاییدیه نداشته و امکان استفاده از آن‌ها وجود ندارد.»

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

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

پروسه کدنویسی در گوگل

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

آن طور که این ‏مهندس ارشد نرم‌افزار گفت این پروسه پیش از کد نویسی آغاز شده و مربوط به کد استایل است. چیزی که فقط ظاهری نبوده و نکات معنایی بایستی در آن رعایت شود، به طور مثال پارامتر Output بایستی به نحوی خاص تعریف شود. همچنین بسیاری از قابلیت‌های زبان ممنوع شده اگرچه به مرور در حال آزادسازی هستند. همچنین راهنمای استایل در نظر گرفته شده که کمک می‌کند همه کدها همگن شوند. این استاندارد کمک می‌کند تا فارغ از روش کار برنامه‌نویس، کدهایی تقریبا شبیه به هم نوشته شود. بخش دیگر فرایند نیز به خوانایی و unit test code باز می‌گردد که موضوعی مهم بوده و نبایستی هیچ پیچیدگی خاصی داشته باشد.

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

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

«همانند قناری که برای نشت گاز در معادن مورد استفاده قرار می‌گیرد، یک سرور را به عنوان قناری در نظر می‌گیریم تا اگر مشکلی پیش آمد تاثیری روی همه کاربران نداشته باشد و ما نیز از مشکلات آن آگاه شویم. در ابتدا کد را روی ۵-۶ تک سرور در ۷-۸ دیتاسنتر قرار می‌دهیم تا یک روز اجرا شود و نتایج آن را براساس شاخص‌های تعیین شده تست می‌کنیم. سپس کد را در نود دیتاسنتر قرار می‌دهیم زیرا با توجه به پویایی سیستم، شفاف‌ترین و قابل اعتمادترین روش تست قرار دادن کد روی نصف یک دیتاسنتر است. اگر هیچ مشکلی نداشت، کد در کل سرویس جهانی عرضه می‌شود.»

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

پروتکل‌های گوگل در لحظه وقوع حادثه

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

او در ادامه به فرهنگ برخورد بدون مقصریابی در گوگل اشاره کرد و گفت:

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

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