(وقت خریده).
حتی آخر هفته‌ها، او به معیارها فکر می‌کرد: «پس اگر زمان را اندازه‌گیری کنم چه؟ چه چیزی به من خواهد داد؟
به راستی دانش زمان چه خواهد داد؟ فرض کنید تحویل 5 روز طول می کشد. بنابراین، بعدی چیست؟ این خوب است یا بد؟ حتی اگر این بد است، پس باید به نحوی این زمان را کاهش دهید. اما چگونه؟
این افکار او را آزار می داد، اما راه حلی نیافت.
ایوان فهمید که به اصل مطلب رسیده است. نمودارهای بی شماری از معیارهایی که قبلا دیده بود مدت ها پیش او را متقاعد کرده بود که روش استاندارد کار نخواهد کرد و اگر او به سادگی رسم کند (، هیچ فایده ای نخواهد داشت.
چگونه بودن؟…
یک متریک مانند یک خط کش چوبی معمولی است. اندازه گیری های انجام شده با کمک آن دلیل را نمی گوید، چرا جسم مورد اندازه گیری دقیقاً همان طولی است که او نشان داد. خط کش به سادگی اندازه خود را نشان می دهد و نه بیشتر. او سنگ فیلسوف نیست، بلکه صرفاً یک تخته چوبی است که با آن می توان اندازه گیری کرد.
"موش فولاد ضد زنگ" نویسنده مورد علاقه اش هری هریسون همیشه می گفت: یک فکر باید به ته مغز برسد و آنجا دراز بکشد، بنابراین ایوان پس از چندین روز رنج بی فایده تصمیم گرفت کار دیگری را انجام دهد ...
چند روز بعد، در حین خواندن مقاله ای در مورد فروشگاه های آنلاین، ایوان ناگهان متوجه شد که مقدار پولی که یک فروشگاه اینترنتی دریافت می کند بستگی به رفتار بازدیدکنندگان سایت دارد. این آنها، بازدیدکنندگان/مشتریان هستند که پول خود را به فروشگاه می دهند و منبع آن هستند. نتیجه نقدی که یک فروشگاه دریافت می کند تحت تأثیر تغییرات رفتار مشتری است نه چیز دیگری.
معلوم شد که برای تغییر مقدار اندازه‌گیری شده، باید بر کسانی که این مقدار را تشکیل می‌دهند، تأثیر بگذاریم، یعنی. برای تغییر مقدار پول یک فروشگاه آنلاین، باید بر رفتار مشتریان این فروشگاه تأثیر گذاشت و برای تغییر زمان تحویل در DevOps، لازم بود تیم‌هایی که این بار ایجاد می‌کنند، یعنی. از DevOps در کار خود استفاده کنند.
ایوان متوجه شد که معیارهای DevOps به هیچ وجه نباید با نمودار نمایش داده شوند. آنها باید نماینده خودشان باشند ابزار جستجو تیم‌های برجسته که زمان تحویل نهایی را شکل می‌دهند.
ایوان فکر کرد که هیچ معیاری دلیلی را نشان نخواهد داد که چرا این یا آن تیم برای تحویل توزیع زمان زیادی صرف کرده است، زیرا در واقعیت ممکن است یک میلیون و یک گاری کوچک وجود داشته باشد و ممکن است فنی نباشند، بلکه سازمانی باشند. آن ها بیشترین چیزی که می توانید از معیارها انتظار داشته باشید این است که تیم ها و نتایج آنها را نشان دهید، و سپس هنوز باید این تیم ها را با پای خود دنبال کنید و متوجه شوید که چه مشکلی با آنها وجود دارد.
از طرف دیگر، شرکت ایوان استانداردی داشت که همه تیم ها را ملزم می کرد تا مجموعه ها را روی چند نیمکت آزمایش کنند. تا زمانی که جایگاه قبلی تکمیل نشده بود، تیم نمی توانست به جایگاه بعدی برود. معلوم شد که اگر فرآیند DevOps را به‌عنوان دنباله‌ای از عبور از غرفه‌ها تصور کنیم، این معیارها می‌توانند زمان صرف شده توسط تیم‌ها را در این غرفه‌ها نشان دهند. با اطلاع از جایگاه و زمان تیم، می‌توان با آنها به طور دقیق‌تری درباره دلایل صحبت کرد.
ایوان بدون معطلی تلفن را برداشت و شماره شخصی را گرفت که به خوبی از جزئیات DevOps آگاه است:
- دنیس، لطفاً به من بگو، آیا می توان به نحوی فهمید که تیم از این یا آن جایگاه عبور کرده است؟
- قطعا. جنکینز ما پرچم را کنار می‌گذارد، اگر بیلد با موفقیت روی نیمکت پخش شود (آزمون را پشت سر بگذارد).
- فوق العاده پرچم چیست؟
- این یک فایل متنی معمولی مانند "stand_OK" یا "stand_FAIL" است که می گوید مونتاژ از پایه عبور کرده یا شکست خورده است. خوب فهمیدی درسته؟
- حدس میزنم بله. آیا در همان پوشه موجود در مخزن که اسمبلی در آن قرار دارد نوشته شده است؟
- آره
- اگر مجمع از میز آزمون عبور نکند چه اتفاقی می افتد؟ آیا نیاز به ساخت یک ساخت جدید دارم؟
- آره
- باشه، ممنون. و یه سوال دیگه اینکه آیا من درست متوجه شدم که میتونم از تاریخ ایجاد پرچم به عنوان تاریخ غرفه استفاده کنم؟
- کاملا!
- فوق العاده!
ایوان با الهام تلفن را قطع کرد و متوجه شد که همه چیز سر جای خود قرار گرفته است. با دانستن تاریخ ایجاد فایل بیلد و تاریخ ایجاد پرچم‌ها، می‌توان به ثانیه محاسبه کرد که تیم‌ها در هر جایگاه چقدر زمان می‌گذرانند و متوجه می‌شویم که بیشترین زمان را در کجا می‌گذرانند.
"با درک اینکه بیشترین زمان در کجا صرف می شود، تیم ها را مشخص می کنیم، به سراغ آنها می رویم و مشکل را بررسی می کنیم." ایوان لبخند زد.
برای فردا، او وظیفه ترسیم معماری سیستم در حال ترسیم را بر عهده خود قرار داد.
ادامه ...
منبع: www.habr.com