مشخص است که صلاحیت CTO تنها بار دومی که این نقش را انجام می دهد آزمایش می شود. زیرا این یک چیز است که چندین سال در یک شرکت کار کنید، با آن تکامل پیدا کنید و با قرار گرفتن در یک بافت فرهنگی، به تدریج مسئولیت بیشتری دریافت کنید. و این کاملاً متفاوت است که مستقیماً به سمت مدیر فنی در شرکتی با چمدان های قدیمی و انبوهی از مشکلات به درستی در زیر فرش قرار گرفته است.

از این نظر، تجربه لئون فایر که او در آن به اشتراک گذاشت DevOpsConf، دقیقاً منحصر به فرد نیست، اما ضربدر تجربه او و تعداد نقش های مختلفی که در طول 20 سال موفق به تجربه آنها شده است، بسیار مفید است. در زیر برش گاه‌شماری از رویدادهای 90 روزه و داستان‌های زیادی وجود دارد که وقتی برای شخص دیگری اتفاق می‌افتد خندیدن به آن‌ها لذت‌بخش است، اما رویارویی با آنها چندان جالب نیست.

لئون به زبان روسی بسیار رنگارنگ صحبت می کند، بنابراین اگر 35-40 دقیقه وقت دارید، توصیه می کنم ویدیو را تماشا کنید. نسخه متن برای صرفه جویی در زمان در زیر.

نسخه اول گزارش، توصیفی ساختاریافته از کار با افراد و فرآیندها بود که حاوی توصیه های مفیدی بود. اما او تمام شگفتی هایی را که در طول راه با آنها مواجه شد، بیان نکرد. بنابراین، قالب را تغییر دادم و مشکلاتی که در شرکت جدید مانند جک در مقابلم ظاهر شد و روش های حل آنها را به ترتیب زمانی ارائه کردم.

یک ماه قبل

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

Teaching Strategies یک رهبر بازار در برنامه درسی برای کودکان بسیار خردسال از بدو تولد تا سه سالگی است. شرکت سنتی "کاغذ" در حال حاضر 40 سال قدمت دارد و نسخه دیجیتال SaaS این پلتفرم 10 سال از عمر آن می گذرد.به تازگی، روند تطبیق فناوری دیجیتال با استانداردهای شرکت آغاز شده است. نسخه "جدید" در سال 2017 راه اندازی شد و تقریباً شبیه نسخه قدیمی بود، فقط بدتر کار می کرد.

جالب ترین چیز این است که ترافیک این شرکت بسیار قابل پیش بینی است - از روز به روز، سال به سال، می توانید به وضوح پیش بینی کنید که چند نفر و چه زمانی می آیند. به عنوان مثال، بین ساعت 13 تا 15 بعد از ظهر همه بچه های مهدکودک به رختخواب می روند و معلمان شروع به وارد کردن اطلاعات می کنند. و این اتفاق هر روز می‌افتد، به‌جز آخر هفته‌ها، زیرا تقریباً هیچ‌کس در تعطیلات آخر هفته کار نمی‌کند.

با کمی نگاه کردن به آینده، متذکر می شوم که من کارم را در دوره بیشترین ترافیک سالانه شروع کردم که به دلایل مختلف جالب است.

این پلتفرم که به نظر می‌رسید تنها 2 سال از عمرش می‌گذشت، پشته‌ای عجیب داشت: ColdFusion و SQL Server از سال 2008. ColdFusion، اگر نمی‌دانید، و به احتمال زیاد نمی‌دانید، یک PHP سازمانی است که در اواسط دهه 90 منتشر شد و از آن زمان من حتی در مورد آن چیزی نشنیده‌ام. همچنین وجود داشت: Ruby، MySQL، PostgreSQL، Java، Go، Python. اما مونولیت اصلی روی ColdFusion و SQL Server اجرا شد.

مشکلات

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

به طور سنتی، متخصصان فنی آنها در گوشه ای می نشستند و نوعی کار را انجام می دادند. اما کسب و کار بیشتر و بیشتر از طریق نسخه دیجیتال شروع شد. بنابراین، در آخرین سال قبل از شروع به کار، افراد جدیدی در شرکت ظاهر شدند: هیئت مدیره، CTO، CPO و مدیر QA. یعنی شرکت شروع به سرمایه گذاری در بخش فناوری کرد.

ردپای میراث سنگین فقط در سیستم ها نبود. این شرکت دارای فرآیندهای میراثی، افراد قدیمی، فرهنگ میراث بود. همه اینها باید تغییر می کرد. من فکر کردم که قطعاً خسته کننده نخواهد بود و تصمیم گرفتم آن را امتحان کنم.

دو روز قبل

دو روز قبل از شروع کار جدید، به دفتر رسیدم، آخرین مدارک را پر کردم، با تیم ملاقات کردم و متوجه شدم که تیم در آن زمان با مشکلی دست و پنجه نرم می کرد. این بود که میانگین زمان بارگذاری صفحه به 4 ثانیه، یعنی 2 بار افزایش یافت.

با قضاوت بر اساس نمودار، چیزی به وضوح اتفاق افتاده است، و مشخص نیست چه چیزی. مشخص شد که مشکل تأخیر شبکه در مرکز داده است: تأخیر 5 میلی‌ثانیه در مرکز داده برای کاربران به 2 ثانیه تبدیل شد. من نمی دانستم چرا این اتفاق افتاد، اما در هر صورت مشخص شد که مشکل در مرکز داده است.

روز اول

دو روز گذشت و در روز اول کارم متوجه شدم که مشکل برطرف نشده است.

به مدت دو روز، صفحات کاربران به طور متوسط ​​در 4 ثانیه بارگذاری می شوند. می پرسم آیا متوجه شده اند که مشکل چیست؟

- بله، بلیط باز کردیم.
- و؟
- خب هنوز جواب ما را ندادند.

سپس متوجه شدم که هر آنچه قبلاً در مورد آن به من گفته شده بود فقط یک نوک کوچک از کوه یخ بود که باید با آن مبارزه کنم.

یک نقل قول خوب وجود دارد که به خوبی با این موضوع مطابقت دارد:

"گاهی اوقات برای تغییر فناوری باید سازمان را تغییر دهید."

اما از آنجایی که کار را در شلوغ ترین زمان سال شروع کردم، مجبور شدم به هر دو گزینه برای حل مشکل نگاه کنم: هم سریع و هم بلند مدت. و با آنچه در حال حاضر حیاتی است شروع کنید.

سه روز

بنابراین، بارگذاری 4 ثانیه طول می کشد و از 13 تا 15 بزرگترین پیک ها است.

در روز سوم در این بازه زمانی، سرعت دانلود به این صورت بود:

از دید من اصلا هیچی کار نکرد. از دید دیگران کمی کندتر از حد معمول کار می کرد. اما این اتفاق نمی افتد - این یک مشکل جدی است.

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

اما نباید فراموش کنیم که قبل از دریافت پاسخ صحیح، باید سوال درست را بپرسید. سوال بعدی من این بود: چند سرور فرانت اند داریم؟ پاسخ "کمی مرا گیج کرد" - ما 17 سرور فرانت اند داشتیم!

- خجالت می کشم بپرسم، اما 150 تقسیم بر 17 حدود 8 را می دهد؟ می گویید هر سرور 8 درخواست در ثانیه می دهد و اگر فردا 160 درخواست در ثانیه باشد به 2 سرور دیگر نیاز داریم؟

البته ما نیازی به سرورهای اضافی نداشتیم. راه حل در خود کد بود و در سطح:

var currentClass = classes.getCurrentClass();
return currentClass;

کارکردی وجود داشت getCurrentClass()، زیرا همه چیز در سایت در چارچوب یک کلاس کار می کند - درست است. و برای این یک تابع در هر صفحه وجود داشت بیش از 200 درخواست.

راه حل از این طریق بسیار ساده بود، حتی لازم نیست چیزی را بازنویسی کنید: فقط دوباره همان اطلاعات را نخواهید.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

من بسیار خوشحال بودم زیرا تصمیم گرفتم در روز سوم مشکل اصلی را پیدا کرده باشم. هر چند ساده لوح بودم، این فقط یکی از مشکلات زیاد بود.

اما حل این مشکل اول نمودار را بسیار پایین تر انداخت.

در همان زمان، بهینه سازی های دیگری را انجام می دادیم. چیزهای زیادی در چشم بود که قابل اصلاح بود. به عنوان مثال، در همان روز سوم متوجه شدم که یک کش در سیستم وجود دارد (در ابتدا فکر می کردم که همه درخواست ها مستقیماً از پایگاه داده می آیند). وقتی به یک کش فکر می کنم، به Redis یا Memcached استاندارد فکر می کنم. اما من تنها کسی بودم که چنین فکر می‌کردم، زیرا آن سیستم از MongoDB و SQL Server برای کش استفاده می‌کرد - همان سیستمی که داده‌ها از آن خوانده می‌شد.

روز دهم

هفته اول با مشکلاتی برخورد کردم که باید همین الان حل می شد. جایی در هفته دوم برای اولین بار به استندآپ آمدم تا با تیم ارتباط برقرار کنم تا ببینم چه اتفاقی می افتد و کل روند چگونه پیش می رود.

دوباره چیز جالبی کشف شد. تیم متشکل از: 18 توسعه دهنده; 8 آزمایش کننده؛ 3 مدیر؛ 2 معمار و همه در تشریفات مشترک شرکت می کردند، یعنی هر روز صبح بیش از 30 نفر به استندآپ می آمدند و می گفتند چه کردند. مشخص است که جلسه 5 یا 15 دقیقه طول نکشید. هیچ کس به حرف کسی گوش نداد زیرا همه بر روی سیستم های مختلف کار می کنند. در این فرم، 2-3 بلیط در ساعت برای یک جلسه نظافت از قبل نتیجه خوبی بود.

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

در نتیجه گرفتیم:

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

ما عمدتاً روی کارایی، بهره‌وری و کیفیت تمرکز کردیم - اینها مشکلاتی است که سعی کردیم با تغییر تیم حل کنیم.

روز یازدهم

در روند تغییر ساختار تیم، نحوه شمارش را کشف کردم داستانامتیاز. 1 SP برابر با یک روز بود و هر بلیط حاوی SP برای توسعه و QA بود، یعنی حداقل 2 SP.

چگونه این را کشف کردم؟

ما یک اشکال پیدا کردیم: در یکی از گزارش ها، که در آن تاریخ شروع و پایان دوره مورد نیاز گزارش وارد شده است، آخرین روز در نظر گرفته نشده است. یعنی جایی در درخواست <= نبود، بلکه به سادگی < بود. به من گفتند که این سه نقطه داستان است، یعنی 3 روز.

پس از این ما:

• سیستم امتیازدهی Story Points تجدید نظر شده است. اکنون رفع اشکالات جزئی که می توانند به سرعت از طریق سیستم عبور کنند سریعتر به دست کاربر می رسد.
• ما شروع به ادغام بلیط های مرتبط برای توسعه و آزمایش کردیم. پیش از این، هر بلیط، هر باگ یک اکوسیستم بسته بود، که به چیز دیگری گره نمی خورد. تغییر سه دکمه در یک صفحه می توانست سه بلیط مختلف با سه فرآیند QA مختلف به جای یک تست خودکار در هر صفحه باشد.
• ما شروع به کار با توسعه دهندگان روی رویکردی برای تخمین هزینه های نیروی کار کردیم. سه روز برای تغییر یک دکمه خنده دار نیست.

روز بیستم

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

اهداف بلند مدت:

• پلت فرم مدیریت شده صدها درخواست در هر صفحه جدی نیستند.
• روندهای قابل پیش بینی اوج‌های ترافیکی دوره‌ای وجود داشت که در نگاه اول با سایر معیارها همبستگی نداشتند - ما باید دلیل این اتفاق را درک می‌کردیم و پیش‌بینی را یاد می‌گرفتیم.
• گسترش پلت فرم کسب و کار به طور مداوم در حال رشد است، کاربران بیشتری وارد می شوند و ترافیک در حال افزایش است.

در گذشته اغلب گفته می شد: بیایید همه چیز را به [زبان/چارچوب] بازنویسی کنیم، همه چیز بهتر کار خواهد کرد!

در بیشتر موارد این کار نمی کند، اگر بازنویسی اصلا کار کند خوب است. بنابراین، ما نیاز به ایجاد یک نقشه راه داشتیم - یک استراتژی خاص که گام به گام چگونگی دستیابی به اهداف تجاری را نشان می دهد (چه کاری انجام خواهیم داد و چرا)، که:

• منعکس کننده ماموریت و اهداف پروژه است.
• اهداف اصلی را اولویت بندی می کند.
• شامل برنامه ای برای دستیابی به آنها است.

قبل از این، هیچ کس با تیم در مورد هدف از ایجاد تغییرات صحبت نکرده بود. این به معیارهای موفقیت مناسب نیاز دارد. برای اولین بار در تاریخ شرکت، KPI را برای گروه فنی تعیین کردیم و این شاخص ها به شاخص های سازمانی گره خوردند.

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

به عنوان مثال، یکی از KPIهای سازمانی افزایش سهم بازار از طریق محصولات جدید است.

چگونه می توانید از هدف داشتن محصولات جدید بیشتر حمایت کنید؟

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

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

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

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

روز سی

در پایان ماه، نکته دیگری را کشف کردم: هیچ کس در تیم Ops من هرگز قراردادهایی را که با مشتریان منعقد می کنیم ندیده است. ممکن است بپرسید چرا باید مخاطبین را ببینید.

• اولاً، زیرا SLA ها در قراردادها مشخص شده اند.
• ثانیا، SLA ها همه متفاوت هستند. هر مشتری با شرایط خاص خود آمد و بخش فروش بدون نگاه کردن امضا کرد.

نکته جالب دیگر این است که در قرارداد با یکی از بزرگترین مشتری ها آمده است که تمام نسخه های نرم افزاری که توسط پلتفرم پشتیبانی می شود باید n-1 باشد، یعنی آخرین نسخه نیست، بلکه ماقبل آخر باشد.

واضح است که اگر پلتفرم مبتنی بر ColdFusion و SQL Server 1 بود که در ماه جولای دیگر اصلاً پشتیبانی نمی شد، چقدر با n-2008 فاصله داشتیم.

روز چهل و پنجم

حوالی اواسط ماه دوم فرصت کافی برای نشستن و انجام دادن داشتم ارزشجریاننقشه برداری به طور کامل برای کل فرآیند اینها اقدامات ضروری است که باید انجام شود، از ایجاد یک محصول تا تحویل آن به مصرف کننده، و باید تا حد امکان با جزئیات توضیح داده شود.

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

وقتی این کار را انجام دادم، دو چیز نظرم را جلب کرد:

• درصد بالایی از بلیط های برگشتی از QA به توسعه دهندگان.
• بررسی درخواست کشش خیلی طولانی شد.

مشکل این بود که اینها نتیجه گیری هایی مانند: به نظر می رسد زمان زیادی می برد، اما ما مطمئن نیستیم که چه مدت.

"شما نمی توانید چیزی را که نمی توانید اندازه گیری کنید، بهبود بخشید."

چگونه می توان میزان جدی بودن مشکل را توجیه کرد؟ روزها را تلف می کند یا ساعت ها؟

برای اندازه‌گیری این، چند مرحله به فرآیند Jira اضافه کردیم: «آماده برای توسعه» و «آماده برای QA» برای اندازه‌گیری مدت زمان انتظار هر بلیط و چند بار بازگشت به یک مرحله خاص.

ما همچنین "در بررسی" را اضافه کردیم تا بدانیم به طور متوسط ​​چند بلیط برای بازبینی وجود دارد، و از این طریق می توانید شروع به رقصیدن کنید. ما معیارهای سیستمی داشتیم، اکنون معیارهای جدیدی اضافه کردیم و شروع به اندازه گیری کردیم:

• کارایی فرآیند: عملکرد و برنامه ریزی شده/تحویل شده
• کیفیت فرآیند: تعداد نقص، نقص از QA.

این واقعا کمک می کند تا بفهمیم چه چیزی خوب پیش می رود و چه چیزی خوب پیش نمی رود.

روز پنجاهم

البته همه اینها خوب و جالب است، اما در اواخر ماه دوم اتفاقی افتاد که در اصل قابل پیش بینی بود، اگرچه من انتظار چنین مقیاسی را نداشتم. مردم شروع به ترک کردند زیرا مدیریت ارشد تغییر کرده بود. افراد جدیدی وارد مدیریت شدند و شروع به تغییر همه چیز کردند و قدیمی ها کنار رفتند. و معمولا در یک شرکت چند ساله همه با هم دوست هستند و همه همدیگر را می شناسند.

این انتظار می رفت، اما مقیاس اخراج غیرمنتظره بود. به عنوان مثال، در یک هفته دو نفر از رهبران تیم به طور همزمان استعفای خود را به میل خود ارائه کردند. بنابراین، من مجبور شدم نه تنها مشکلات دیگر را فراموش کنم، بلکه روی آن تمرکز کنم ایجاد یک تیم. این یک مشکل طولانی و دشوار برای حل است، اما باید با آن برخورد می شد زیرا می خواستم افرادی را که باقی مانده اند (یا بیشتر آنها) را نجات دهم. برای حفظ روحیه در تیم باید به نحوی نسبت به رفتن مردم واکنش نشان می داد.

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

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

من پاسخ خوبی برای این سوال ندارم که تعادل درست چیست، چگونه آن را حفظ کنیم، چند نفر را نگه داریم و چقدر باید فشار دهیم. این یک فرآیند کاملاً فردی است.

روز پنجاه و یکم

شروع کردم به نگاه دقیق به تیم تا بفهمم چه کسی دارم و یک بار دیگر به یاد آوردم:

"بیشتر مشکلات مشکلات مردم است."

من متوجه شده ام که تیم به عنوان چنین - هم Dev و هم Ops - سه مشکل بزرگ دارد:

• رضایت از وضعیت فعلی.
• فقدان مسئولیت - زیرا هیچ کس تا به حال نتایج کار مجریان را برای تأثیرگذاری بر تجارت به ارمغان نیاورده است.
• ترس از تغییر.

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

اما بدون تغییر چیزی نمی توانید بهتر شوید.

من یک گفتگوی کاملاً پوچ با یک کارمند داشتم، ایده های خود را برای بهینه سازی به او گفتم، که او به من گفت:
- اوه، تو ندیدی سال گذشته چه داشتیم!
- پس چی؟
"الان خیلی بهتر از آنچه بود."
- پس بهتر از این نمی شود؟
- برای چی؟

سوال خوب - چرا؟ انگار الان بهتر از قبل است، پس همه چیز به اندازه کافی خوب است. این منجر به عدم مسئولیت می شود که در اصل کاملاً طبیعی است. همانطور که گفتم گروه فنی کمی در حاشیه بود. این شرکت معتقد بود که آنها باید وجود داشته باشند، اما هیچ کس هرگز استانداردها را تعیین نکرده است. پشتیبانی فنی هرگز SLA را ندیده بود، بنابراین برای گروه کاملاً "قابل قبول" بود (و این بیشتر مرا متاثر کرد):

• 12 ثانیه بارگذاری;
• 5-10 دقیقه توقف در هر نسخه.
• عیب یابی مشکلات حیاتی روزها و هفته ها طول می کشد.
• کمبود پرسنل وظیفه 24x7 / در حال حاضر.

هیچ کس هرگز سعی نکرده است بپرسد که چرا ما این کار را بهتر انجام نمی دهیم، و هیچ کس هرگز متوجه نشده است که لازم نیست اینگونه باشد.

به عنوان پاداش، یک مشکل دیگر وجود داشت: عدم تجربه. بزرگترها رفتند و تیم جوان باقی مانده در رژیم قبلی بزرگ شدند و مسموم شدند.

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

این ترس از پرسیدن سوال به شیوه های جالبی خود را نشان می دهد. به عنوان مثال، شما می‌پرسید: "با این کار چگونه عمل می‌کنید؟" - "چند ساعت مانده است، من دارم تمام می کنم." روز بعد دوباره سوال می کنید جواب می گیرید که همه چیز خوب است اما یک مشکل وجود داشت حتما تا آخر روز آماده می شود. یک روز دیگر می گذرد و تا زمانی که شما را به دیوار می چسبانند و مجبور می کنید با کسی صحبت کنید، این کار ادامه دارد. آدمی می خواهد خودش مشکلی را حل کند، معتقد است که اگر خودش آن را حل نکند، شکست بزرگی خواهد بود.

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

ثانیاً افرادی که از ناتوان جلوه دادن می ترسند بیش از حد تجزیه و تحلیل کنید. وقتی می گویید دقیقاً چه کاری باید انجام شود، شروع می شود: "نه، اگر اینجا به آن فکر کنیم چه؟" از این نظر، شرکت ما منحصر به فرد نیست، این یک مشکل استاندارد برای جوانان است.

در پاسخ، من اقدامات زیر را معرفی کردم:

• قانون 30 دقیقه اگر نمی توانید مشکل را در نیم ساعت حل کنید، از کسی کمک بخواهید. این با درجات مختلف موفقیت کار می کند، زیرا مردم هنوز نمی پرسند، اما حداقل این روند آغاز شده است.
• همه چیز را به جز ذات حذف کنید، در تخمین مهلت تکمیل یک کار، یعنی فقط مدت زمان نوشتن کد را در نظر بگیرید.
• یادگیری مداوم برای کسانی که بیش از حد تحلیل می کنند. این فقط کار مداوم با مردم است.

روز شصت

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

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

اما توسعه دهندگان تجربه ای در خرید سرور و مهارت تعیین اندازه مورد نیاز سرورها ندارند، زیرا قبلاً به آن نیاز نداشتند. و معمولاً تفاوت بین مقیاس پذیری و عملکرد را کاملاً درک نمی کنند.

نتایج موجودی:

• ما از همان مرکز داده خارج شدیم.
• ما قرارداد را با 3 سرویس ورود فسخ کردیم. از آنجا که ما 5 تا از آنها داشتیم - هر توسعه دهنده ای که شروع به بازی با چیزی می کرد، یک برنامه جدید می گرفت.
• 7 سیستم AWS خاموش شد. باز هم هیچ کس پروژه های مرده را متوقف نکرد؛ همه آنها به کار خود ادامه دادند.
• کاهش هزینه های نرم افزاری تا 6 برابر.

روز هفتاد و پنجم

زمان گذشت و در عرض دو ماه و نیم باید با هیئت مدیره ملاقات می کردم. هیئت مدیره ما بهتر و بدتر از بقیه نیست، مثل همه هیئت مدیره ها می خواهد همه چیز را بداند. مردم پول سرمایه گذاری می کنند و می خواهند بفهمند که کاری که ما انجام می دهیم چقدر با شاخص های کلیدی عملکرد تنظیم می شود.

هیئت مدیره هر ماه اطلاعات زیادی دریافت می کند: تعداد کاربران، رشد آنها، خدماتی که استفاده می کنند و چگونه، عملکرد و بهره وری، و در نهایت، متوسط ​​سرعت بارگذاری صفحه.

تنها مشکل این است که من معتقدم میانگین شر محض است. اما توضیح این موضوع برای هیئت مدیره بسیار دشوار است. آنها عادت کرده اند که با اعداد جمع شده کار کنند، و نه برای مثال، پخش زمان بارگذاری در ثانیه.

نکات جالبی در این زمینه وجود داشت. به عنوان مثال، من گفتم که باید ترافیک را بین وب سرورهای جداگانه تقسیم کنیم، بسته به نوع محتوا.

یعنی ColdFusion از Jetty و nginx عبور می کند و صفحات را راه اندازی می کند. و تصاویر، JS و CSS از طریق یک nginx جداگانه با پیکربندی های خاص خود عبور می کنند. این یک روش نسبتاً استاندارد است که من در مورد آن صحبت می کنم نوشت چند سال پیش. در نتیجه تصاویر بسیار سریعتر بارگذاری می شوند و ... میانگین سرعت بارگذاری 200 میلی ثانیه افزایش یافته است.

این به این دلیل اتفاق افتاد که نمودار بر اساس داده هایی که با Jetty ارائه می شود ساخته شده است. یعنی محتوای سریع در محاسبه گنجانده نشده است - مقدار متوسط ​​افزایش یافته است. این برای ما واضح بود، خندیدیم، اما چطور می‌توانیم به هیئت مدیره توضیح دهیم که چرا کاری کردیم و اوضاع ۱۲ درصد بدتر شد؟

روز هشتاد و پنجم

در پایان ماه سوم، متوجه شدم که یک چیز وجود دارد که اصلاً روی آن حساب نکرده بودم: زمان. هر چیزی که در مورد آن صحبت کردم زمان می برد.

این تقویم هفتگی واقعی من است - فقط یک هفته کاری، نه خیلی شلوغ. برای همه چیز وقت کافی نیست. بنابراین، مجدداً باید افرادی را استخدام کنید که به شما کمک کنند تا با مشکلات کنار بیایید.

نتیجه

این همش نیست. در این داستان، من حتی به نحوه کار ما با محصول و تلاش برای هماهنگ کردن با موج عمومی، یا نحوه ادغام پشتیبانی فنی یا نحوه حل مشکلات فنی دیگر نرسیدم. به عنوان مثال، من کاملاً تصادفی فهمیدم که در بزرگترین جداول پایگاه داده از ما استفاده نمی کنیم SEQUENCE. ما یک تابع خودنویس داریم nextID، و در یک معامله استفاده نمی شود.

میلیون ها چیز مشابه دیگر وجود داشت که می توانستیم برای مدت طولانی در مورد آنها صحبت کنیم. اما مهمترین چیزی که هنوز باید گفت فرهنگ است.

این فرهنگ یا فقدان آن است که منجر به سایر مشکلات می شود. ما در تلاشیم تا فرهنگی بسازیم که مردم:

• از شکست نمی ترسید؛
• از اشتباهات درس بگیر؛
• همکاری با سایر تیم ها؛
• ابتکار عمل
• مسئولیت پذیرفتن؛
• از نتیجه به عنوان یک هدف استقبال کنید.
• جشن موفقیت

با این همه چیز دیگر خواهد آمد.

لئون فایر در توییتر, فیس بوک و متوسط.

دو استراتژی در مورد میراث وجود دارد: به هر قیمتی از کار با آن اجتناب کنید، یا شجاعانه بر مشکلات مرتبط غلبه کنید. ما ج DevOpsConf ما مسیر دوم را طی می کنیم و فرآیندها و رویکردها را تغییر می دهیم. به ما بپیوندید در یوتیوب, لیست پستی и تلگرامو با هم یک فرهنگ DevOps را پیاده سازی خواهیم کرد.

منبع: www.habr.com