دا معلومه ده چې د CTO وړتیا یوازې د دویم ځل لپاره ازموینه کیږي چې هغه دا رول ترسره کوي. ځکه چې دا یو شی دی چې په یوه شرکت کې د څو کلونو لپاره کار وکړي، د هغې سره وده وکړي او په ورته کلتوري شرایطو کې وي، ورو ورو ډیر مسؤلیت ترلاسه کوي. او دا یو بل څه دی چې مستقیم په یوه شرکت کې د تخنیکي رییس مقام ته د میراثي سامانونو سره راشي او یو شمیر ستونزې په ښه ډول د غالۍ لاندې تیریږي.

په دې معنی، د لیون فائر تجربه، کوم چې هغه یې شریک کړ DevOpsConf، په حقیقت کې ځانګړی ندی ، مګر د هغه تجربې او د مختلف رولونو شمیر چې هغه د 20 کلونو په اوږدو کې هڅه کړې ، دا خورا ګټور دی. د کټ لاندې د 90 ورځو پیښو تاریخ او ډیری کیسې دي چې په خندا کولو کې خوندور دي کله چې دوی د بل چا سره پیښیږي ، مګر دا دومره خوندور ندي چې په فرد کې ورسره مخ شي.

لیون په روسیه کې خورا رنګه خبرې کوي، نو که تاسو 35-40 دقیقې لرئ، زه وړاندیز کوم چې ویډیو وګورئ. د وخت خوندي کولو لپاره لاندې متن نسخه.

د راپور لومړۍ نسخه د خلکو او پروسو سره د کار کولو یو ښه جوړښت شوی تشریح و، چې ګټور وړاندیزونه پکې شامل وو. مګر هغې ټول هغه حیرانتیاوې ندي بیان کړي چې په لاره کې ورسره مخ شوي. له همدې امله، ما بڼه بدله کړه او هغه ستونزې چې زما په وړاندې په نوي شرکت کې د جیک ان باکس په څیر راڅرګندې شوې، او په تاریخي ترتیب کې یې د حل کولو میتودونه وړاندې کړل.

یوه میاشت مخکې

د ډیرو ښو کیسو په څیر، دا د الکول سره پیل شو. موږ د ملګرو سره په بار کې ناست وو، او لکه څنګه چې د معلوماتي ټکنالوجۍ متخصصینو په منځ کې تمه کیده، هرڅوک د خپلو ستونزو په اړه ژړل. یو له دوی څخه یوازې دنده بدله کړې وه او د ټیکنالوژۍ، خلکو او ټیم سره یې د خپلو ستونزو په اړه خبرې کولې. هرڅومره چې ما اوریدلي ، نور زه پوهیدم چې هغه باید ما وګماري ، ځکه چې دا هغه ډول ستونزې دي چې زه یې په تیرو 15 کلونو کې حل کوم. ما ورته وویل، او بله ورځ موږ په کاري چاپیریال کې ولیدل. دا شرکت د تدریس ستراتیژیو په نوم یادیږي.

د ښوونې ستراتیژی د زیږون څخه تر دریو کلونو پورې د خورا کوچني ماشومانو لپاره په نصاب کې د بازار مشر دی. دودیز "کاغذ" شرکت لا دمخه 40 کلن دی، او د پلیټ فارم ډیجیټل SaaS نسخه 10 کلن دی، په نسبي توګه پدې وروستیو کې، د شرکت معیارونو سره د ډیجیټل ټیکنالوژۍ د تطبیق پروسه پیل شوه. "نوی" نسخه په 2017 کې پیل شوې او نږدې د زاړه په څیر وه، یوازې دا بد کار کوي.

تر ټولو په زړه پورې خبره دا ده چې د دې شرکت ټرافیک خورا د وړاندوینې وړ دی - له ورځې څخه تر کال پورې، تاسو کولی شئ په روښانه توګه وړاندوینه وکړئ چې څومره خلک به راشي او کله. د مثال په توګه، د ماسپښین له 13 څخه تر 15 بجو پورې ټول ماشومان په وړکتون کې بستر ته ځي او ښوونکي د معلوماتو په داخلولو پیل کوي. او دا هره ورځ پیښیږي، پرته د اونۍ پای، ځکه چې نږدې هیڅوک د اونۍ په پای کې کار نه کوي.

یو څه مخکې ګورم، زه به یادونه وکړم چې ما خپل کار د لوړ کلني ټرافیک په جریان کې پیل کړ، کوم چې د مختلفو دلیلونو لپاره په زړه پورې دی.

پلیټ فارم، چې داسې ښکاري چې یوازې 2 کلن دی، یو ځانګړی سټیک درلود: کولډ فیوژن او SQL سرور له 2008 څخه. کولډ فیوژن ، که تاسو نه پوهیږئ ، او ډیری احتمال تاسو نه پوهیږئ ، د PHP یو شرکت دی چې د 90s په مینځ کې راپورته شوی ، او له هغه وخت راهیسې ما حتی د دې په اړه ندي اوریدلي. دلته هم شتون درلود: روبي، مای ایس کیو ایل، پوسټگری ایس کیو ایل، جاوا، ګو، پیتون. مګر اصلي مونولیت په کولډ فیوژن او ایس کیو ایل سرور کې وګرځید.

ستونزې

هرڅومره چې ما د شرکت کارمندانو سره د کار په اړه خبرې وکړې او کومې ستونزې ورسره مخ شوې ، هومره زه پوهیدم چې ستونزې یوازې تخنیکي ندي. ښه، ټیکنالوژي زوړ ده - او دوی په دې کار نه دی کړی، مګر د ټیم او پروسو سره ستونزې وې، او شرکت پدې پوهیدل پیل کړل.

په دودیز ډول، د دوی تخنیکان په کونج کې ناست وو او یو ډول کار یې کاوه. مګر ډیر او ډیر سوداګرۍ د ډیجیټل نسخې له لارې پرمخ وړل پیل کړل. له همدې امله، په تیر کال کې مخکې له دې چې ما کار پیل کړ، نوي کسان په شرکت کې راڅرګند شول: د رییسانو بورډ، CTO، CPO او QA رییس. دا دی، شرکت د ټیکنالوژۍ په برخه کې پانګونه پیل کړه.

د دروند میراث نښې یوازې په سیسټمونو کې نه وې. شرکت د میراث پروسې، میراث خلک، میراث کلتور درلود. دا ټول باید بدل شي. ما فکر کاوه چې دا به یقینا ستړي نه وي، او پریکړه یې وکړه چې دا هڅه وکړي.

دوه ورځې وړاندې

د نوې دندې له پیلولو دوه ورځې وړاندې، زه دفتر ته ورسیدم، وروستی کاغذ مې ډک کړ، له ټیم سره مې وکتل، او وموندله چې ټیم په دې وخت کې له یوې ستونزې سره مخ و. دا وو چې د پاڼې د پورته کولو اوسط وخت 4 ثانیو ته ورسید، دا 2 ځله.

د ګراف لخوا قضاوت کول، یو څه په واضح ډول پیښ شوي، او دا روښانه نده چې څه. دا معلومه شوه چې ستونزه د ډیټا مرکز کې د شبکې ځنډ وه: د معلوماتو مرکز کې 5 ms ځنډ د کاروونکو لپاره 2 s ته بدل شو. زه نه پوهیږم چې دا ولې پیښ شوي، مګر په هر حالت کې دا معلومه شوه چې ستونزه د معلوماتو مرکز کې وه.

لومړۍ ورځ

دوه ورځې تیرې شوې او زما د کار په لومړۍ ورځ ما وموندله چې ستونزه نه وه تللې.

د دوو ورځو لپاره، د کاروونکو پاڼې په اوسط ډول په 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;

زه ډیر خوشحاله وم ځکه چې ما پریکړه وکړه چې یوازې په دریمه ورځ ما اصلي ستونزه وموندله. لکه څنګه چې زه وم، دا یوازې یو له ډیرو ستونزو څخه و.

مګر د دې لومړۍ ستونزې حل کولو ګراف خورا ټیټ کړی.

په ورته وخت کې، موږ نور اصلاح کول. په لید کې ډیر شیان وو چې کیدی شي ثابت شي. د مثال په توګه ، په ورته دریمه ورځ ما وموندله چې وروسته په سیسټم کې کیچ شتون درلود (په لومړي سر کې ما فکر کاوه چې ټولې غوښتنې مستقیم له ډیټابیس څخه راځي). کله چې زه د کیچ په اړه فکر کوم، زه د معیاري ریډیس یا میمکیچ په اړه فکر کوم. مګر زه یوازینی کس وم چې داسې فکر یې کاوه، ځکه چې دا سیسټم د مونګو ډی بی او ایس کیو ایل سرور د کیچ کولو لپاره کارولی و - هماغه یو چې له هغې څخه ډاټا یوازې لوستل کیده.

لسمه ورځ

لومړۍ اونۍ ما د ستونزو سره معامله وکړه چې اوس حل ته اړتیا لري. په دویمه اونۍ کې یو ځای، زه د لومړي ځل لپاره سټینډ اپ ته راغلم ترڅو د ټیم سره اړیکه ونیسم، ترڅو وګورم چې څه پیښیږي او ټوله پروسه څنګه روانه ده.

په زړه پورې یو څه بیا وموندل شو. په ټیم کې شامل وو: 18 پراختیا کونکي؛ ۸ ازمويونکي؛ ۳ مدیران؛ ۲ معماران. او دوی ټولو په ګډو عباداتو کې برخه اخیسته، یعنی هر سهار له ۳۰ څخه زیات کسان ولاړو او څه به یې ویل. څرګنده دی وی چی غونډه ۵ یا ۱۵ دقیقی نه وه. هیڅوک چا ته غوږ نه نیسي ځکه چې هرڅوک په بیلابیلو سیسټمونو کار کوي. په دې فورمه کې، په هر ساعت کې د 8-3 ټکټونه د ښکلا ناستې لپاره لا دمخه ښه پایله وه.

لومړی شی چې موږ یې وکړل ټیم ​​په څو محصول لینونو ویشلی و. د مختلفو برخو او سیسټمونو لپاره، موږ جلا ټیمونه تخصیص کړل، کوم چې پراختیا کونکي، ټیسټران، د محصول مدیران، او د سوداګرۍ شنونکي شامل وو.

په پایله کې موږ ترلاسه کړل:

• د لاریونونو او لاریونونو کمول.
• د محصول د موضوع پوهه.
• د مالکیت احساس. کله چې خلکو هر وخت د سیسټمونو سره ټیکر کاوه، دوی پوهیدل چې بل څوک به د دوی د کیګونو سره کار وکړي، مګر پخپله نه.
• د ډلو ترمنځ همکاري. د ویلو اړتیا نشته، QA مخکې د پروګرام کونکو سره ډیر اړیکه نه وه نیولې، محصول خپل کار کړی، او نور. اوس دوی د مسؤلیت ګډ ټکی لري.

موږ په عمده توګه په موثریت، تولید او کیفیت تمرکز وکړ - دا هغه ستونزې دي چې موږ یې د ټیم د بدلون سره حل کولو هڅه کړې.

یوولسمه ورځ

د ټیم جوړښت بدلولو په بهیر کې، ما وموندله چې څنګه شمیرل کیږي کیسهټکي. 1 SP د یوې ورځې سره مساوي و، او په هر ټکټ کې د پراختیا او QA دواړو لپاره SP شتون درلود، دا لږترلږه 2 SP.

ما دا څنګه کشف کړه؟

موږ یوه ستونزه وموندله: په یو راپور کې ، چیرې چې د هغه دورې پیل او پای نیټه چې راپور ته اړتیا لري داخلیږي ، وروستۍ ورځ په پام کې نه نیول کیږي. دا دی، په غوښتنه کې کوم ځای نه و <=، مګر ساده <. ما ته وویل شول چې دا درې کیسه ټکي دي، دا دی د 3 ورځو.

له دې وروسته موږ:

• د کیسې پوائنټونو درجه بندي سیسټم بیاکتنه شوی. اوس د کوچنیو بګونو لپاره اصلاحات چې په چټکۍ سره د سیسټم له لارې تیریږي کارونکي ته ګړندي رسي.
• موږ د پراختیا او ازموینې لپاره اړوند ټکټونه یوځای کول پیل کړل. پخوا، هر ټکټ، هر بګ یو تړلی اکوسیستم و، په بل څه پورې تړلی نه و. په یوه پاڼه کې د دریو بټونو بدلول کیدای شي په هره پاڼه کې د یو اتوماتیک ازموینې پرځای درې مختلف QA پروسې سره درې مختلف ټکټونه وي.
• موږ د پراختیا کونکو سره د کار لګښتونو اټکل کولو طریقې باندې کار پیل کړ. د یوې تڼۍ بدلولو لپاره درې ورځې مسخره نه ده.

شلمه ورځ

د لومړۍ میاشتې په مینځ کې ، وضعیت یو څه ارام شو ، ما وموندله چې اساسا څه پیښیږي ، او دمخه یې راتلونکي ته کتل او د اوږدمهاله حلونو په اړه فکر کول پیل کړل.

اوږد مهاله موخې:

• مدیریت شوی پلیټ فارم. په هره پاڼه کې په سلګونو غوښتنې جدي ندي.
• د وړاندوینې وړ رجحانات. د ترافیکي دورې لوړوالی شتون درلود چې په لومړي نظر کې د نورو میټریکونو سره تړاو نه درلود - موږ اړتیا لرو پوه شو چې ولې دا پیښ شوي او وړاندوینه کول زده کړل.
• د پلیټ فارم پراخول. سوداګرۍ په دوامداره توګه وده کوي، ډیر او ډیر کاروونکي راځي، او ترافیک مخ په ډیریدو دی.

په تیرو وختونو کې ډیری وختونه ویل کیدل: "راځئ چې هرڅه په [ژبه/ چوکاټ] کې بیا ولیکئ، هرڅه به ښه کار وکړي!"

په ډیری قضیو کې دا کار نه کوي، دا ښه ده که بیا لیکل په بشپړ ډول کار وکړي. له همدې امله، موږ اړتیا لرو چې د سړک نقشه جوړه کړو - یوه ځانګړې ستراتیژي چې ګام په ګام دا روښانه کوي چې څنګه د سوداګرۍ اهداف به ترلاسه شي (موږ به څه وکړو او ولې)، کوم چې:

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

تر دې وړاندې هیچا هم په لوبډله کې د کوم بدلون د راوستلو په اړه خبرې نه دي کړي. دا د بریالیتوب سمه میترونو ته اړتیا لري. د شرکت په تاریخ کې د لومړي ځل لپاره، موږ د تخنیکي ګروپ لپاره KPIs ترتیب کړل، او دا شاخصونه د سازماني سره تړل شوي.

دا دی، سازماني KPIs د ټیمونو لخوا ملاتړ کیږي، او د ټیم KPIs د انفرادي KPIs لخوا ملاتړ کیږي. که نه نو، که ټیکنالوژیک KPIs د سازماني سره سمون نه خوري، نو هرڅوک په خپل ځان کمپلې راوباسي.

د بیلګې په توګه، یو له سازماني KPIs څخه د نوي محصولاتو له لارې د بازار ونډه ډیروي.

تاسو څنګه کولی شئ د نورو نوي محصولاتو درلودلو هدف ملاتړ وکړئ؟

• لومړی، موږ غواړو د نیمګړتیاوو د حل کولو پر ځای د نویو محصولاتو په پراختیا کې ډیر وخت ولګوو. دا یو منطقي حل دی چې اندازه کول یې اسانه دي.
• دوهم، موږ غواړو د راکړې ورکړې په حجم کې د زیاتوالي ملاتړ وکړو، ځکه چې د بازار ونډه ډیره وي، ډیر کاروونکي او په وینا، ډیر ټرافیک.

بیا انفرادي KPIs چې په ګروپ کې اجرا کیدی شي د مثال په توګه به په هغه ځای کې وي چیرې چې اصلي نیمګړتیاوې راځي. که تاسو په ځانګړې توګه دې برخې ته تمرکز وکړئ، تاسو کولی شئ ډاډ ترلاسه کړئ چې ډیر لږ نیمګړتیاوې شتون لري، او بیا د نوي محصولاتو پراختیا او بیا د سازماني KPIs مالتړ لپاره وخت به ډیر شي.

په دې توګه، هره پریکړه، د بیا لیکلو کوډ په شمول، باید د ځانګړو اهدافو ملاتړ وکړي چې شرکت زموږ لپاره ټاکلي دي (تنظیمي وده، نوي ځانګړتیاوې، استخدام).

د دې پروسې په جریان کې، یو په زړه پورې شی روښانه شو، کوم چې نه یوازې د تخنیکانو لپاره، بلکې په عمومي توګه په شرکت کې خبر شو: ټول ټکټونه باید لږترلږه په یو KPI تمرکز وکړي. دا دی، که یو محصول ووایی چې دا غواړي یو نوی خصوصیت رامینځته کړي، لومړی پوښتنه باید وپوښتل شي: "د کوم KPI دا خصوصیت ملاتړ کوي؟" که نه، نو بخښنه غواړئ - دا د غیر ضروري ځانګړتیا په څیر ښکاري.

دېرشمه ورځ

د میاشتې په پای کې، ما یو بل توپیر وموندل: زما د Ops ټیم کې هیڅوک هیڅکله هغه قراردادونه ندي لیدلي چې موږ یې د پیرودونکو سره داخلوو. تاسو ممکن پوښتنه وکړئ چې ولې تاسو اړتیا لرئ اړیکې وګورئ.

• لومړی، ځکه چې SLAs په قراردادونو کې مشخص شوي.
• دوهم، SLAs ټول مختلف دي. هر پیرودونکی د خپلو اړتیاو سره راغلی، او د پلور څانګه پرته له لیدلو لاسلیک کړه.

یو بل په زړه پوری نزاکت دا دی چې د یو له لوی پیرودونکو سره تړون وايي چې د پلیټ فارم لخوا ملاتړ شوي د سافټویر ټولې نسخې باید n-1 وي ، دا وروستۍ نسخه نه ده ، مګر حتمي نسخه.

دا روښانه ده چې موږ له n-1 څخه څومره لرې یو که چیرې پلیټ فارم د ColdFusion او SQL Server 2008 پراساس و ، کوم چې نور په جولای کې هیڅ ملاتړ نه و.

پنځه څلویښتمه ورځ

د دوهمې میاشتې په نیمایي کې ما د ناست او ترسره کولو لپاره کافي وخت درلود ارزښتد ويالو دنقشه په بشپړه توګه د ټولې پروسې لپاره. دا اړین ګامونه دي چې باید واخیستل شي ، د محصول رامینځته کولو څخه نیولې پیرودونکي ته یې وړاندې کولو پورې ، او دوی باید د امکان تر حده په تفصیل سره تشریح شي.

تاسو پروسه په کوچنیو ټوټو وویشئ او وګورئ چې څه ډیر وخت نیسي ، څه شی اصلاح کیدی شي ، ښه کیدی شي ، او نور. د مثال په توګه، د محصول غوښتنې لپاره څومره وخت نیسي چې د چمتو کولو له لارې تیریږي، کله هغه ټکټ ته رسیږي چې یو پراختیاګر یې اخیستلی شي، QA، او نور. نو تاسو هر انفرادي ګام په تفصیل سره وګورئ او د هغه څه په اړه فکر وکړئ چې مطلوب کیدی شي.

کله چې ما دا وکړل، دوه شیان زما سترګې ونیولې:

• د ټکټونو لوړه سلنه د QA څخه بیرته پراختیا کونکو ته راستانه شوي؛
• د غوښتنې بیاکتنې ډیر وخت واخیست.

ستونزه دا وه چې دا پایلې وې لکه: داسې ښکاري چې ډیر وخت نیسي، مګر موږ ډاډه نه یو چې څومره وخت.

"تاسو نشئ کولی هغه څه ښه کړئ چې تاسو یې اندازه نشئ کولی."

څنګه توجیه کړو چې ستونزه څومره جدي ده؟ ایا دا ورځې یا ساعتونه ضایع کوي؟

د دې اندازه کولو لپاره، موږ د جیرا پروسې ته یو څو مرحلې اضافه کړې: "د dev لپاره چمتو" او "QA لپاره چمتو" د دې اندازه کولو لپاره چې هر ټیکټ څومره وخت انتظار کوي او څو ځله یو ځانګړي مرحلې ته راستنیږي.

موږ "په بیاکتنه کې" هم اضافه کړل ترڅو پوه شو چې په اوسط ډول د بیاکتنې لپاره څومره ټکټونه دي، او له دې څخه تاسو نڅا پیل کولی شئ. موږ سیسټم میټریک درلود، اوس موږ نوي میټریکونه اضافه کړل او اندازه یې پیل کړه:

• د پروسې موثریت: فعالیت او پلان شوی / تحویل شوی.
• د پروسې کیفیت: د نیمګړتیاوو شمیر، د QA څخه نیمګړتیاوې.

دا واقعیا مرسته کوي چې پوه شي چې څه ښه روان دي او څه ښه ندي.

پنځوسمه ورځ

دا ټول، البته، ښه او په زړه پورې دي، مګر د دویمې میاشتې په پای کې یو څه پیښ شوي چې په اصل کې، د وړاندوینې وړ و، که څه هم ما د داسې اندازې تمه نه درلوده. خلکو په وتلو پیل وکړ ځکه چې لوړ مدیریت بدل شوی و. نوي خلک په اداره کې راغلل او هرڅه یې بدلول پیل کړل، او زاړه یې پریښودل. او معمولا په یوه شرکت کې چې څو کلن وي، هرڅوک ملګري وي او هرڅوک یو بل پیژني.

دا تمه کیده، مګر د ګوښه کولو کچه غیر متوقع وه. د مثال په توګه، په یوه اونۍ کې دوه ټیمونو په یو وخت کې د خپلې خوښې استعفا وړاندې کړه. له همدې امله، زه باید نه یوازې د نورو ستونزو په اړه هیر کړم، مګر تمرکز وکړم ټیم جوړول. دا یوه اوږده او ستونزمنه ستونزه ده چې حل شي، مګر دا باید ورسره معامله وشي ځکه چې ما غوښتل هغه خلک خوندي کړم چې پاتې دي (یا ډیری یې). دا اړینه وه چې یو څه د دې حقیقت په اړه غبرګون وښيي چې خلک په ټیم کې د مورال ساتلو لپاره پریښودل.

په تیوري کې، دا ښه دی: یو نوی کس راځي چې بشپړ کارټ بلانچ ولري، څوک چې د ټیم مهارتونه ارزوي او د پرسونل ځای نیسي. په حقیقت کې، تاسو نشئ کولی یوازې د ډیری دلیلونو لپاره نوي خلک راوړي. توازن تل اړین دی.

• زاړه او نوي. موږ اړتیا لرو چې زاړه خلک وساتو چې کولی شي بدلون ومومي او د ماموریت ملاتړ وکړي. مګر په ورته وخت کې ، موږ اړتیا لرو چې نوې وینه راوړو ، موږ به لږ وروسته پدې اړه وغږیږو.
• تجربه. ما د ښه ځوانو سره ډیرې خبرې وکړې چې لیواله وو او غوښتل یې چې زموږ سره کار وکړي. مګر زه نشم کولی دوی په غاړه واخلم ځکه چې کافي مشران شتون نلري چې د ځوانو ملاتړ وکړي او د دوی لپاره د ښوونکي په توګه عمل وکړي. دا اړینه وه چې لومړی لوړ او بیا یوازې ځوانان استخدام شي.
• گاجر او چپنه.

زه د دې پوښتنې لپاره ښه ځواب نلرم چې سم توازن څه شی دی، څنګه یې ساتل، څومره خلک ساتل او څومره فشار ورکول. دا یو خالص انفرادي پروسه ده.

یوویشتمه ورځ

ما ټیم ته نږدې کتل پیل کړل ترڅو پوه شم چې څوک یې لري، او یو ځل بیا ما په یاد ولرم:

"ډیری ستونزې د خلکو ستونزې دي."

ما وموندله چې ټیم لکه څنګه چې - دواړه دیو او اوپس - درې لوی ستونزې لري:

• له اوسني وضعیت څخه رضایت.
• د مسؤلیت نشتوالی - ځکه چې هیڅوک هیڅکله د لوبغاړو د کار پایلې نه دي راوړي ترڅو په سوداګرۍ اغیزه وکړي.
• د بدلون ویره.

بدلون تل تاسو د خپل آرامۍ زون څخه لرې کوي، او ځوانان چې ځوانان دي، دوی ډیر بدلون نه خوښوي ځکه چې دوی نه پوهیږي ولې او دوی نه پوهیږي چې څنګه. ترټولو عام ځواب چې ما اوریدلی دی دا دی، "موږ هیڅکله دا نه دی کړی." برسېره پر دې، دا د بشپړ ناپوهۍ نقطې ته رسیدلی - لږ څه بدلونونه نشي کولی پرته له دې چې یو څوک ناراضه وي. او مهمه نده چې بدلونونه د دوی په کار څومره اغیزه کوي، خلکو وویل: "نه، ولې؟ دا کار نه کوي."

مګر تاسو د هیڅ شی بدلولو پرته ښه نشئ ترلاسه کولی.

ما د یو کارمند سره بالکل بې ځایه خبرې وکړې، ما هغه ته د اصلاح کولو لپاره خپل نظرونه بیان کړل، چې ما ورته وویل:
- اوه، تاسو هغه څه ونه لیدل چې موږ تیر کال درلود!
- نو څه؟
"اوس دا د پخوا په پرتله خورا ښه دی."
- نو، دا نور ښه نشي کیدی؟
- د څه له پاره؟

ښه پوښتنه - ولې؟ دا لکه څنګه چې دا اوس د هغه په ​​​​پرتله ښه ده، نو هرڅه ښه دي. دا د مسؤلیت نشتوالي لامل کیږي ، کوم چې په اصولو کې بالکل عادي خبره ده. لکه څنګه چې ما وویل، تخنیکي ډله یو څه په څنګ کې وه. شرکت باور درلود چې دوی باید شتون ولري، مګر هیڅوک هیڅکله معیارونه ندي ټاکلي. تخنیکي مالتړ هیڅکله SLA نه دی لیدلی، نو دا د ډلې لپاره خورا "د منلو وړ" و (او دا ما ډیر زیانمن کړ):

• 12 ثانیې بار کول؛
• د هرې خوشې کیدو وخت 5-10 دقیقې؛
• د جدي ستونزو حل کول ورځې او اونۍ وخت نیسي؛
• د دندې پرسونل نشتوالی 24x7 / آن کال.

هیڅوک هیڅکله هڅه نه ده کړې چې پوښتنه وکړي چې ولې موږ دا غوره نه کوو، او هیڅوک هیڅکله نه پوهیږي چې دا باید داسې نه وي.

د بونس په توګه، یوه بله ستونزه وه: د تجربې نشتوالی. مشران لاړل، او پاتې ځوان ټیم د پخواني رژیم لاندې وده وکړه او د هغې لخوا مسموم شو.

له دې ټولو سره سره خلک د ناکامۍ او بې کفایتۍ له وېرې هم وو. دا په حقیقت کې څرګند شوی چې لومړی، دوی په هیڅ حالت کې د مرستې غوښتنه نه ده شوې. موږ څو ځله د یوې ډلې په توګه او په انفرادي ډول خبرې کړې دي، او ما وویل، "یوه پوښتنه وکړئ که تاسو نه پوهیږئ چې څنګه یو څه وکړئ." زه په خپل ځان باور لرم او پوهیږم چې زه کولی شم هره ستونزه حل کړم، مګر دا به وخت ونیسي. له همدې امله، که زه د یو چا څخه پوښتنه کولی شم چې پوهیږي چې دا څنګه په 10 دقیقو کې حل کړي، زه به پوښتنه وکړم. څومره چې لږ تجربه لرئ، هغومره له پوښتنې کولو څخه ډارېږئ، ځکه فکر کوئ چې تاسو به بې کفایته وګڼل شي.

د پوښتنو دا ویره ځان په زړه پورې لارو څرګندوي. د مثال په توګه، تاسو پوښتنه کوئ: "تاسو د دې دندې سره څنګه یاست؟" - "یو څو ساعته پاتې دي، زه لا دمخه پای ته رسیدلی یم." بله ورځ بیا پوښتنه وکړه، ځواب مو ترلاسه کړ چې هر څه سم دي، خو یوه ستونزه وه، د ورځې تر پایه به خامخا چمتو کېږي. بله ورځ تیریږي، او تر هغه چې تاسو دیوال ته ځړول شوي یاست او د یو چا سره خبرې کولو ته اړ یاست، دا دوام لري. یو سړی غواړي یوه ستونزه پخپله حل کړي؛ هغه باور لري چې که هغه پخپله حل نه کړي، دا به لویه ناکامي وي.

له همدې کبله پراختیا ورکوونکو اټکلونه لوړ کړل. دا هماغه کيسه وه، کله چې دوی د يو کار په اړه بحث کاوه، نو ماته يې داسې څېره راکړه چې ډېر حيران شوم. کوم ته چې ما ته ویل شوي و چې د پراختیا کونکي په اټکلونو کې، پراختیا کونکي هغه وخت شاملوي چې ټکټ به د QA څخه بیرته راستانه شي، ځکه چې دوی به هلته غلطۍ ومومي، او هغه وخت چې PR به یې واخلي، او هغه وخت چې خلک باید بیاکتنه وکړي. دا به بوخت وي - دا چې هرڅه، هر څه چې ممکن وي.

دوهم، هغه خلک چې د بې کفایتۍ څخه ویره لري ډیر تحلیل. کله چې تاسو ووایاست چې واقعیا څه کولو ته اړتیا لري، دا پیل کیږي: "نه، که موږ دلته د هغې په اړه فکر وکړو؟" په دې معنی، زموږ شرکت ځانګړی ندی؛ دا د ځوانانو لپاره معیاري ستونزه ده.

په ځواب کې، ما لاندې کړنې معرفي کړې:

• قاعده 30 دقیقې. که تاسو په نیم ساعت کې ستونزه نه شئ حل کولی، د یو چا څخه مرسته وغواړئ. دا د بریالیتوب مختلف درجې سره کار کوي، ځکه چې خلک لاهم پوښتنه نه کوي، مګر لږترلږه پروسه پیل شوې.
• هرڅه لرې کړئ مګر جوهرد کار بشپړولو لپاره د نیټې نیټې اټکل کولو کې، دا یوازې په پام کې ونیسئ چې د کوډ لیکلو لپاره به څومره وخت ونیسي.
• د ژوند په اوږدو کې زده کړه د هغو کسانو لپاره چې ډیر تحلیل کوي. دا یوازې د خلکو سره دوامداره کار دی.

شپیتمه ورځ

پداسې حال کې چې ما دا ټول کول، دا وخت و چې بودیجه معلومه کړم. البته، ما ډیر په زړه پوري شیان وموندل چیرې چې موږ خپلې پیسې مصرف کړې. د مثال په توګه، موږ د FTP سرور سره په جلا ډیټا مرکز کې بشپړ ریک درلود، کوم چې د یو پیرودونکي لخوا کارول کیده. دا معلومه شوه چې "... موږ حرکت وکړ، مګر هغه همداسې پاتې شو، موږ هغه بدل نه کړ." دا 2 کاله مخکې وه.

د ځانګړي ګټو څخه د بادل خدماتو بل و. زه باور لرم چې د لوړ بادل بل اصلي لامل هغه پراختیا کونکي دي چې په خپل ژوند کې د لومړي ځل لپاره سرورونو ته لامحدود لاسرسی لري. دوی اړتیا نلري پوښتنه وکړي: "مهرباني وکړئ ما ته د ازموینې سرور راکړئ،" دوی کولی شي دا پخپله واخلي. برسیره پردې، پراختیا کونکي تل غواړي داسې یو ښه سیسټم جوړ کړي چې فیسبوک او Netflix به حسد کړي.

مګر پراختیا کونکي د سرورونو پیرودلو کې تجربه نلري او د سرورونو مطلوب اندازې ټاکلو مهارت نلري، ځکه چې دوی مخکې ورته اړتیا نه درلوده. او دوی معمولا د توزیع او فعالیت ترمینځ توپیر نه پوهیږي.

د موجوداتو پایلې:

• موږ ورته د معلوماتو مرکز پریښود.
• موږ د 3 لاګ خدماتو سره قرارداد فسخ کړ. ځکه چې موږ له دوی څخه 5 درلودل - هر پرمخ وړونکي چې د یو څه سره لوبې پیل کړي یو نوی یې اخیستی.
• 7 د AWS سیسټمونه وتړل شول. بیا هم چا د مړو پروژو مخه ونه نیوله، ټولو کار ته دوام ورکړ.
• د سافټویر لګښتونه 6 ځله کم شوي.

پنځه پنځوسمه ورځ

وخت تېر شو، او په دوه نیمو میاشتو کې زه باید د مدیرانو بورډ سره ووینم. زموږ د مدیره هیئت تر نورو ښه یا بد نه دی؛ لکه د ټولو مدیرانو بورډونو په څیر، دا غواړي په هرڅه پوه شي. خلک پیسې پانګونه کوي او غواړي پوه شي چې موږ څه کوو د KPIs په ټاکلو کې څومره مناسب دي.

د مدیرانو بورډ هره میاشت ډیری معلومات ترلاسه کوي: د کاروونکو شمیر، د دوی وده، کوم خدمتونه چې دوی کاروي او څنګه، فعالیت او تولید، او په پای کې، د اوسط پاڼې د پورته کولو سرعت.

یوازینۍ ستونزه دا ده چې زه باور لرم چې اوسط خالص بد دی. مګر دا خورا ستونزمن کار دی چې د مدیرانو بورډ ته دا تشریح کړي. دوی د راټولو شمیرو سره کار کولو سره عادت دي، او نه، د بیلګې په توګه، په هر ثانیه کې د بارولو وخت خپرول.

په دې اړه ځینې په زړه پورې ټکي وو. د مثال په توګه، ما وویل چې موږ اړتیا لرو چې د منځپانګې ډول پورې اړوند د جلا ویب سرورونو ترمنځ ټرافيک وویشو.

دا دی، ColdFusion د Jetty او nginx له لارې ځي او پاڼې پیلوي. او انځورونه، JS او CSS د خپلو ترتیبونو سره د جلا نګینکس له لارې ځي. دا یو مناسب معیاري تمرین دی چې زه یې په اړه خبرې کوم لیکلی څو کاله وړاندې د پایلې په توګه، انځورونه خورا ګړندي پورته کیږي، او ... د اوسط ډاونلوډ سرعت 200 ms ډیر شوی.

دا پیښ شوي ځکه چې ګراف د هغه معلوماتو پراساس جوړ شوی چې د جیټي سره راځي. دا دی، چټک محتويات په محاسبه کې شامل نه دي - اوسط ارزښت کود شوی. دا موږ ته روښانه وه، موږ وخندل، مګر موږ څنګه د مدیرانو بورډ ته تشریح کړو چې ولې موږ یو څه وکړل او شیان 12٪ خراب شول؟

اته پنځوسمه ورځ

د دریمې میاشتې په پای کې، ما پوهیده چې یو شی و چې ما په هیڅ ډول حساب نه درلود: وخت. هرڅه چې ما په اړه خبرې وکړې وخت نیسي.

دا زما اصلي اونۍ کیلنڈر دی - یوازې د کار اونۍ، ډیر بوخت نه. د هر څه لپاره کافي وخت نشته. له همدې امله، یوځل بیا، تاسو اړتیا لرئ هغه خلک استخدام کړئ چې تاسو سره به د ستونزو سره مقابله کې مرسته وکړي.

پایلې

دا ټول نه دي. په دې کیسه کې، ما حتی دا هم نه ده ترلاسه کړې چې موږ څنګه د محصول سره کار وکړ او هڅه یې وکړه چې عمومي څپې ته ورسیږو، یا موږ څنګه تخنیکي مالتړ سره یوځای کړو، یا موږ څنګه نورې تخنیکي ستونزې حل کړې. د مثال په توګه ، ما په ناڅاپي ډول زده کړل چې په ډیټابیس کې ترټولو لوی میزونو کې چې موږ یې نه کاروو SEQUENCE. موږ پخپله لیکل شوی فعالیت لرو nextID، او دا په معامله کې نه کارول کیږي.

دلته یو ملیون نور ورته شیان وو چې موږ یې د اوږدې مودې لپاره خبرې کولی شو. مګر ترټولو مهم شی چې لاهم باید وویل شي کلتور دی.

دا کلتور یا د هغې نشتوالی دی چې د نورو ټولو ستونزو لامل کیږي. موږ هڅه کوو چې یو کلتور رامینځته کړو چیرې چې خلک:

• له ناکامۍ نه ډارېږي؛
• له تېروتنو زده کړه؛
• د نورو ټیمونو سره همکاري؛
• نوښت
• مسؤلیت په غاړه اخیستل
• د یوې موخې په توګه پایلې ته ښه راغلاست؛
• بریالیتوب لمانځل.

له دې سره به نور هر څه راشي.

لیون اور په ټویټر کې, facebook او په متوسط.

د میراث په اړه دوه ستراتیژیانې شتون لري: په هر قیمت کې د هغې سره کار کولو څخه ډډه وکړئ، یا په زړورتیا سره د تړلو ستونزو سره مخ شئ. موږ ج DevOpsConf موږ دویمه لاره اخلو، پروسې او طریقې بدلوو. له موږ سره یوځای شئ یوتیوب, خبر پاڼه и تلګرام، او په ګډه به موږ د DevOps کلتور پلي کړو.

سرچینه: www.habr.com