ترجمه مقاله به طور اختصاصی برای دانشجویان دوره تهیه شده است .
ماموریت اینترکام شخصی کردن تجارت آنلاین است. اما شخصی سازی یک محصول زمانی که کار نمی کند غیرممکن است. . Uptime برای موفقیت کسب و کار ما بسیار مهم است، نه تنها به این دلیل که مشتریان ما به ما پول می دهند، بلکه به این دلیل که ما استفاده می کنیم . اگر خدمات ما کارساز نباشد، به معنای واقعی کلمه درد مشتریان خود را احساس می کنیم.
عملکرد بدون وقفه به عوامل زیادی مانند معماری نرم افزار و کیفیت کار روزانه بستگی دارد. با این حال، اغلب اوقات به این واقعیت مربوط می شود که فردی که همیشه در تماس است به تماس ها پاسخ می دهد . این پشتیبانی فنی می تواند یک ابزار قدرتمند مشتری محور باشد که کمک مهندسان را با آنچه مشتریان هنگام خرید محصول شما دریافت می کنند ترکیب می کند. همچنین فرصت بسیار خوبی برای یادگیری و رشد می‌گشاید، زیرا در نهایت، شکست‌ها و اشتباهات می‌تواند زمینه خوبی برای تمرین مهارت‌ها و درک مکانیسم‌های کاری پیچیده باشد.
حفظ "همیشه در تماس" خارج از ساعات کاری برای زندگی شما مضر است.
اما در عین حال، «همیشه متصل بودن» می‌تواند تأثیر مضری بر زندگی شما داشته باشد. شما باید آماده باشید تا به اعلان خرابی چیزی سریع و شایسته پاسخ دهید. حتی اگر در آن لحظه خاص با پیجر تماس نگیرید، حالت "همیشه روشن" احساس ناراحتی را القا می کند، من خودم این را از تجربه شخصی می دانم. به خصوص به این دلیل، کیفیت خواب بدتر می شود. قرار گرفتن منظم در منطقه دسترسی در هر زمانی از روز می‌تواند منجر به فرسودگی شغلی، بی‌تفاوتی یا به طور کلی میل به دیدن کامپیوتر دیگر شود.
تاریخچه حالت "همیشه متصل" در اینترکام
در روزهای اولیه اینترکام، CTO ما سیاران به تنهایی تمام تیم پشتیبانی فنی XNUMX ساعته، چه در داخل و چه خارج از دفتر بود. با رشد اینترکام، یک گروه ضربت برای کمک به سیاران ایجاد شد. مدت کوتاهی پس از آن، تیم‌های توسعه‌دهنده جدید شروع به ایجاد بسیاری از ویژگی‌ها و سرویس‌های جدید کردند و قبلاً تمام مسئولیت‌های پشتیبانی فنی را بر عهده گرفتند.
در هر لحظه افراد زیادی "در خط" بودند.
در آن زمان، این رویکرد بی‌معنا به نظر می‌رسید، زیرا راهی آسان برای مقیاس‌بندی تیم پشتیبانی فنی ما در هر لحظه بود، با ارزش‌های ما همخوانی داشت، و ما را خوشحال می‌کرد. . در نتیجه، بدون هیچ برنامه‌ای، به چهار یا پنج تیم رسیدیم که به طور منظم در ساعات غیر کاری با مشتریان تماس می‌گرفتند. بقیه تیم های توسعه نقاط سخت زیادی نداشتند که می توانست خطا ایجاد کند، بنابراین به ندرت، و حتی زمانی، تماس گرفته می شدند.
ما متوجه شدیم که در موقعیتی قرار داشتیم که مکانیک پشتیبانی فنی داشتیم که باید به آنها افتخار کنیم و تعدادی از مسائل حیاتی که می خواستیم به آنها رسیدگی کنیم، مانند:
- در هر زمان، افراد زیادی آماده پذیرش این چالش بودند. زیرساخت‌های ما به اندازه‌ای بزرگ نبود که به حداقل پنج مهندس توسعه نیاز داشته باشیم که بدون روزهای تعطیل معمولی کار کنند.
- کیفیت هشدارها و روش‌های تماس ما در بین تیم‌ها یکسان نبود، ما از فرآیندهای بررسی موقتی برای هشدارهای مشکل جدید و موجود استفاده کردیم. دستورالعمل‌های موجود در runbook (که باید در هنگام مطرح شدن موضوع رعایت شود) عمدتاً به دلیل عدم حضورشان مشخص بود.
- بسته به تیمی که مهندسان برای آن کار می کردند، انتظارات متناقضی داشتند. به عنوان مثال، فقط اولین تیم پشتیبانی فنی برای شیفت های وظیفه و تعطیلات مختل شده بود.
- معلوم شد که یک سطح کلی از تحمل برای تماس های غیر ضروری در ساعات فرد وجود دارد.
- در نهایت، این نوع کار برای همه نیست. گاهی اوقات شرایط زندگی نشان می دهد که شیفت کاری به بهترین وجه بر افراد تأثیر نمی گذارد.
پیدا کردن حالت مناسب "همیشه متصل"
ما تصمیم گرفته‌ایم یک تیم مجازی جدید ایجاد کنیم که کارهای پشتیبانی فنی هر تیم را در زمان تعطیلی آنها انجام دهد. این تیم متشکل از داوطلبان خواهد بود، نه سربازان وظیفه از هیچ تیمی در سازمان. مهندسان تیم مجازی تقریباً هر شش ماه یکبار چرخش می‌کردند و هفته‌ها «در ارتباط» بودند. خوشبختانه، مشکلی برای یافتن داوطلبان کافی برای تشکیل یک تیم مجازی نداشتیم.
در نتیجه، تیم پشتیبانی ما از 30 نفر به تنها 6 یا 7 نفر کاهش یافت.
سپس تیم موافقت کرد و تعریف کرد که هشدارها و توضیحات runbook چگونه باید باشد، و روند ارسال هشدارها به تیم پشتیبانی جدید را تشریح کرد. آنها تمام هشدارهای موجود در کد را با استفاده از ماژول Terraform شناسایی کردند و شروع به استفاده از بررسی همتا برای هر تغییر کردند. ما سطحی از غرامت برای یک شیفت هفتگی را معرفی کردیم که به خوبی برای افسران وظیفه مناسب بود. ما همچنین یک تیم سطح دوم تشدید شده ایجاد کردیم که فقط از مدیران تشکیل شده بود. این دستور باید تنها نقطه تشدید برای مهندسین پشتیبانی فنی باشد.
ما چندین ماه کار سختی داشتیم که طی آن این روند را ایجاد کردیم، در نتیجه، اکنون نه 30 مهندس مانند گذشته در تماس بودند، بلکه فقط 6 یا 7 مهندس در تماس بودند. در طول ساعات کاری، تیم ها به طور مستقل با مشکلات مربوط به عملکرد یا خدمات خود برخورد می کنند. این زمان معمولاً بیشترین تعداد خرابی ها را به خود اختصاص می دهد، اما بقیه زمان ها، پشتیبانی فنی توسط داوطلبان انجام می شود.
چه آموخته ایم
پس از راه‌اندازی تیم پشتیبانی فنی مجازی خود، انتظار سیل وظایف جدید مانند بررسی علل مشکلات یا گردهمایی عمومی برای حل یک مشکل واحد را داشتیم که باعث خرابی شده است. با این حال، تیم‌های توسعه‌دهنده ما مسئولیت کامل عواملی که باعث خرابی‌ها می‌شوند را بر عهده گرفتند و هر واکنش بعدی معمولاً اقدام فوری بود. ما همچنین باید از شرایطی که در آن وظیفه مشاوره فنی به تیمی که از آن آمده بازگردانده می‌شود، اجتناب می‌کردیم تا مهندسان مجبور نباشند بعد از ساعت‌ها با هم تماس بگیرند.
تماس های خارج از ساعت به کمتر از 10 تماس در ماه کاهش یافته است.
به طور رسمی، روند تشدید ما به ندرت مورد استفاده قرار می گرفت. تصور رایج‌تر این بود که مهندس به‌طور غیررسمی توسط تیمی که در حال حاضر آنلاین بودند، به‌ویژه بچه‌های ما در دفتر سانفرانسیسکو، کمک می‌کرد. بسیاری از مشکلات از طریق کار تیمی و حل و فصل فوری رفع یا کاهش یافته است.
مهندسان دفتر ما در سانفرانسیسکو به عنوان یک تیم کامل به تیم ملحق می شوند و از پشتیبانی فنی معمولی فراتر می روند. برخی از هزینه‌ها درگیر بود، اما گسترش عضویت تیم پشتیبانی ما در مکان‌های مختلف به نفع ما بوده است، زیرا ثابت کرده است که راه خوبی برای ایجاد روابط، تقویت آنها و کسب اطلاعات بیشتر در مورد پشته فناوری است که همه ما با آن کار می‌کنیم.
در تیم های ما، کار توسعه دهندگان Intercom سازگارتر شده است و ما می توانیم با اطمینان در مورد مزایای موقعیت یک مهندس سیستم در وب سایت خود صحبت کنیم. ، بیان می کند که اگر خودتان نمی خواهید، نیازی نیست همیشه در تماس باشید.
همراه با کار اساسی تثبیت و مقیاس بندی انبارهای داده ما، تمرکز مداوم بر حل مشکل منجر به کاهش تماس های خارج از ساعت به کمتر از 10 تماس در ماه شده است. ما به این تعداد بسیار افتخار می کنیم.
ما همچنان به کار بر روی حفظ و بهبود تیم پشتیبانی فنی خود ادامه می‌دهیم، و با رشد اینترکام، ممکن است لازم باشد در تصمیم‌گیری‌های خود تجدید نظر کنیم، زیرا آنچه امروز کار می‌کند ممکن است دفعه بعد که تعداد کارکنان ما دو برابر شود، لزوماً کارساز نیست. با این حال، این تجربه برای سازمان ما بسیار مثبت بوده است و کیفیت زندگی مهندسان توسعه ما، کیفیت پاسخ‌های ما به چالش‌ها و مهم‌تر از همه، تجربه مشتریان ما را تا حد زیادی بهبود می‌بخشد.
منبع: www.habr.com