اهو معلوم ٿئي ٿو ته CTO جي قابليت جو امتحان صرف ٻيو ڀيرو هن ڪردار کي انجام ڏئي ٿو. ڇاڪاڻ ته اها هڪ شيءِ آهي هڪ ڪمپني ۾ ڪيترن سالن تائين ڪم ڪرڻ، ان سان گڏ ترقي ڪريو ۽، ساڳئي ثقافتي حوالي سان، آهستي آهستي وڌيڪ ذميواريون حاصل ڪريو. ۽ اهو بلڪل ٻيو آهي ته سڌو سنئون هڪ ڪمپني ۾ ٽيڪنيڪل ڊائريڪٽر جي پوزيشن ۾ اچي ويريسي سامان سان ۽ مسئلن جو هڪ گروپ صاف طور تي قالين جي هيٺان پکڙيل آهي.

انهي لحاظ کان، ليون فائر جو تجربو، جيڪو هن تي شيئر ڪيو DevOpsConf، بلڪل منفرد ناهي، پر هن جي تجربي ۽ مختلف ڪردارن جو تعداد جيڪو هن 20 سالن دوران ڪوشش ڪرڻ جي ڪوشش ڪئي، اهو تمام مفيد آهي. هيٺ ڏنل ڪٽ 90 ڏينهن کان وڌيڪ واقعن جو هڪ ڪرنالوجي آهي ۽ ڪيتريون ئي ڪهاڻيون آهن جن تي کلڻ ۾ مزو اچي ٿو جڏهن اهي ڪنهن ٻئي سان ٿين ٿيون، پر جن کي انسان ۾ منهن ڏيڻ ايترو مزو نه آهي.

ليون روسي ۾ تمام رنگا رنگ ڳالهائيندو آهي، تنهنڪري جيڪڏهن توهان وٽ 35-40 منٽ آهن، آئون وڊيو ڏسڻ جي صلاح ڏيان ٿو. هيٺ ڏنل وقت بچائڻ لاءِ ٽيڪسٽ ورزن.

رپورٽ جو پهريون نسخو ماڻهن ۽ عملن سان گڏ ڪم ڪرڻ جي چڱيءَ طرح ٺهيل تفصيل هئي، جنهن ۾ مفيد سفارشون شامل هيون. پر هوءَ انهن سڀني حيرانگين جو اظهار نه ڪيو جيڪي رستي ۾ سامهون آيا. تنهن ڪري، مون فارميٽ کي تبديل ڪيو ۽ نئين ڪمپني ۾ جيڪ-ان-دي-باڪس وانگر منهنجي سامهون ايندڙ مسئلن کي پيش ڪيو، ۽ انهن کي تاريخ جي ترتيب ۾ حل ڪرڻ جا طريقا.

هڪ مهينو اڳ

ڪيتريون ئي سٺيون ڪهاڻيون وانگر، هي هڪ شراب سان شروع ڪيو. اسان دوستن سان گڏ هڪ بار ۾ ويٺا هئاسين، ۽ آئي ٽي ماهرن جي وچ ۾ توقع ڪئي وئي، هرڪو پنهنجي مسئلن بابت روئي رهيو هو. انهن مان هڪ صرف نوڪري تبديل ڪئي هئي ۽ ٽيڪنالاجي سان، ماڻهن سان، ۽ ٽيم سان هن جي مسئلن بابت ڳالهائي رهيو هو. جيتري قدر مون ٻڌو، اوترو ئي مون محسوس ڪيو ته هن کي صرف مون کي نوڪري ڏيڻ گهرجي، ڇاڪاڻ ته اهي ئي مسئلا آهن جن کي مان گذريل 15 سالن کان حل ڪري رهيو آهيان. مون کيس ائين چيو، ۽ ٻئي ڏينهن اسان ڪم جي ماحول ۾ ملاقات ڪئي. ڪمپني کي تدريس واري حڪمت عملي سڏيو ويندو هو.

تدريسي حڪمت عمليون نصاب ۾ هڪ مارڪيٽ ليڊر آهي تمام ننڍڙن ٻارن لاءِ پيدائش کان وٺي ٽن سالن جي عمر تائين. روايتي "پيپر" ڪمپني اڳ ۾ ئي 40 سال پراڻي آهي، ۽ پليٽ فارم جو ڊجيٽل SaaS نسخو 10 سال پراڻو آهي. نسبتا تازو، ڪمپني جي معيار سان ڊجيٽل ٽيڪنالاجي کي اپنائڻ جو عمل شروع ٿيو. "نئون" ورزن 2017 ۾ شروع ڪيو ويو ۽ تقريبن پراڻي وانگر هو، صرف اهو وڌيڪ خراب ڪم ڪيو.

سڀ کان وڌيڪ دلچسپ ڳالهه اها آهي ته هن ڪمپني جي ٽرئفڪ تمام گهڻو اڳڪٿي ڪري سگهجي ٿو - ڏينهن کان ڏينهن، سال کان سال تائين، توهان واضح طور تي اڳڪٿي ڪري سگهو ٿا ته ڪيترا ماڻهو ايندا ۽ ڪڏهن. مثال طور، 13 کان 15 وڳي جي وچ ۾ ڪنڊر گارٽن ۾ سڀئي ٻار بستري تي ويندا آهن ۽ استاد معلومات داخل ڪرڻ شروع ڪندا آهن. ۽ اهو هر روز ٿئي ٿو، هفتي جي آخر ۾، ڇاڪاڻ ته تقريبا ڪو به هفتي جي آخر ۾ ڪم نٿو ڪري.

ٿورو اڳتي ڏسندي، مان نوٽ ڪندس ته مون پنهنجو ڪم شروع ڪيو، ان عرصي دوران سڀ کان وڌيڪ سالياني ٽرئفڪ، جيڪو مختلف سببن جي ڪري دلچسپ آهي.

پليٽ فارم، جيڪو لڳي ٿو صرف 2 سال پراڻي، هڪ خاص اسٽيڪ هو: ColdFusion ۽ SQL سرور 2008 کان. ColdFusion، جيڪڏهن توهان نٿا ڄاڻو، ۽ گهڻو ڪري توهان کي خبر ناهي، هڪ انٽرنيشنل پي ايڇ پي آهي جيڪو 90 جي وچ ۾ ٻاهر آيو، ۽ ان کان پوء مون ان جي باري ۾ نه ٻڌو آهي. هتي پڻ هئا: روبي، MySQL، PostgreSQL، Java، Go، Python. پر مکيه monolith ColdFusion ۽ SQL سرور تي هليو ويو.

پريشاني

وڌيڪ مون ڪمپني جي ملازمن سان ڪم بابت ڳالهايو ۽ ڪهڙيون مشڪلاتون پيش آيون، وڌيڪ مون محسوس ڪيو ته مسئلا صرف فني طور تي نه هئا. ٺيڪ آهي، ٽيڪنالاجي پراڻي آهي - ۽ انهن ان تي ڪم نه ڪيو، پر ٽيم ۽ پروسيس سان گڏ مسئلا هئا، ۽ ڪمپني ان کي سمجهڻ شروع ڪيو.

روايتي طور تي، سندن ٽيڪنيڪي ڪنڊ ۾ ويهندا هئا ۽ ڪجهه قسم جو ڪم ڪيو. پر وڌيڪ ۽ وڌيڪ ڪاروبار ڊجيٽل ورزن ذريعي وڃڻ شروع ڪيو. تنهن ڪري، گذريل سال کان اڳ مون ڪم ڪرڻ شروع ڪيو، ڪمپني ۾ نوان ظاهر ٿيا: ڊائريڪٽرن جو بورڊ، CTO، CPO ۽ QA ڊائريڪٽر. اهو آهي، ڪمپني ٽيڪنالاجي شعبي ۾ سيڙپڪاري ڪرڻ شروع ڪيو.

هڪ ڳري ورثي جا نشان نه رڳو سسٽم ۾ هئا. ڪمپنيءَ وٽ ميراثي عمل، ورثي وارا ماڻهو، ميراثي ڪلچر هئا. اهو سڀ ڪجهه تبديل ڪرڻو پيو. مون سوچيو ته اهو ضرور بورنگ نه هوندو، ۽ ان کي ڪوشش ڪرڻ جو فيصلو ڪيو.

ٻه ڏينهن اڳ

نئين نوڪري شروع ڪرڻ کان ٻه ڏينهن اڳ، مان آفيس پهتس، آخري ڪاغذ ڀريو، ٽيم سان ملاقات ڪئي، ۽ معلوم ڪيو ته ٽيم ان وقت ڪنهن مسئلي سان وڙهندي هئي. اهو هو ته سراسري صفحو لوڊ ٿيڻ وقت 4 سيڪنڊن ڏانهن وڌيو، يعني 2 ڀيرا.

گراف جي ذريعي، ڪجهه واضح طور تي ٿيو، ۽ اهو واضح ناهي ته ڇا. اهو ظاهر ٿيو ته مسئلو ڊيٽا سينٽر ۾ نيٽ ورڪ جي دير هئي: ڊيٽا سينٽر ۾ 5 ايم ايس ويڪرائيزيشن صارفين لاء 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;

مان ڏاڍي خوش ٿيس ڇاڪاڻ ته مون فيصلو ڪيو ته صرف ٽئين ڏينهن مون کي بنيادي مسئلو مليو آهي. بيوقوف جيئن ته مان هو، اهو صرف ڪيترن ئي مسئلن مان هڪ هو.

پر هن پهرين مسئلي کي حل ڪرڻ سان گراف تمام گهڻو گهٽجي ويو.

ساڳئي وقت، اسان ٻين اصلاحن کي ڪري رهيا هئاسين. اتي ڪيتريون ئي شيون نظر آيون جيڪي طئي ڪري سگهجن ٿيون. مثال طور، ساڳئي ٽئين ڏينهن تي مون دريافت ڪيو ته سسٽم ۾ هڪ ڪيش آهي سڀ کان پوء (پهريان مون سوچيو ته سڀئي درخواستون سڌو سنئون ڊيٽابيس مان اچي رهيون آهن). جڏهن مان هڪ ڪيش جي باري ۾ سوچيان ٿو، مان سمجهان ٿو معياري ريڊس يا ميمڪچڊ. پر مان اڪيلو هو جنهن ائين سوچيو، ڇاڪاڻ ته اهو سسٽم مونگو ڊي بي ۽ SQL سرور استعمال ڪيو ڪيشنگ لاءِ - اهو ساڳيو جنهن مان ڊيٽا صرف پڙهي وئي هئي.

ڏهه ڏينهن

پھرين ھفتي مون انھن مسئلن سان ڊيل ڪيو جن کي ھاڻي حل ڪرڻ جي ضرورت آھي. ٻئي هفتي ۾، مان پهريون ڀيرو اسٽينڊ اپ تي آيو آهيان ته ٽيم سان رابطو ڪري، اهو ڏسڻ لاء ته ڇا ٿي رهيو آهي ۽ سڄو عمل ڪيئن ٿي رهيو آهي.

ڪجهه دلچسپ ٻيهر دريافت ڪيو ويو. ٽيم تي مشتمل هئي: 18 ڊولپر؛ 8 ٽيسٽ ڪندڙ؛ 3 مينيجر؛ 2 معمار. ۽ انهن سڀني گڏيل رسمن ۾ شرڪت ڪئي، يعني هر صبح 30 کان وڌيڪ ماڻهو اسٽينڊ اپ تي ايندا هئا ۽ ٻڌايو ته انهن ڇا ڪيو. واضح رهي ته ملاقات 5 يا 15 منٽ نه ٿي هئي. ڪنهن به ڪنهن جي ڳالهه نه ٻڌي ڇو ته هرڪو مختلف سسٽم تي ڪم ڪري ٿو. هن فارم ۾، هڪ سينگار سيشن لاء في ڪلاڪ 2-3 ٽڪيٽ اڳ ۾ ئي سٺو نتيجو هو.

پهرين شيء جيڪا اسان ڪئي اها ٽيم کي ڪيترن ئي پراڊڪٽ لائنن ۾ ورهايو ويو. مختلف حصن ۽ سسٽم لاءِ، اسان الڳ الڳ ٽيمون مختص ڪيون، جن ۾ ڊولپر، ٽيسٽ ڪندڙ، پراڊڪٽ مئنيجر، ۽ ڪاروباري تجزيه نگار شامل هئا.

نتيجي طور، اسان حاصل ڪيو:

• اسٽينڊ اپ ۽ ريلي کي گهٽائڻ.
• پيداوار جي مضمون جي ڄاڻ.
• ملڪيت جو احساس. جڏهن ماڻهو هر وقت سسٽم سان ٽينڪر ڪندا هئا، انهن کي خبر هئي ته ڪنهن ٻئي کي گهڻو ڪري انهن جي بگ سان ڪم ڪرڻو پوندو، پر پاڻ کي نه.
• گروپن جي وچ ۾ تعاون. چوڻ جي ضرورت ناهي، QA اڳ پروگرامرز سان گهڻو رابطو نه ڪيو، پيداوار پنهنجي ڪم ڪيو، وغيره. هاڻي انهن وٽ ذميواري جو هڪ عام نقطو آهي.

اسان بنيادي طور تي ڪارڪردگي، پيداوار ۽ معيار تي ڌيان ڏنو - اهي اهي مسئلا آهن جن کي اسان ٽيم جي تبديلي سان حل ڪرڻ جي ڪوشش ڪئي.

يارنهن ڏينهن

ٽيم جي جوڙجڪ کي تبديل ڪرڻ جي عمل ۾، مون دريافت ڪيو ته ڪيئن شمار ڪجي مستجون پوائينٽون:. 1 SP هڪ ڏينهن جي برابر هو، ۽ هر ٽڪيٽ تي مشتمل SP ٻنهي ترقي ۽ QA لاءِ، يعني گهٽ ۾ گهٽ 2 SP.

مون کي اهو ڪيئن دريافت ڪيو؟

اسان کي ھڪڙو بگ مليو: ھڪڙي رپورٽ ۾، جتي مدت جي شروعات ۽ آخري تاريخ داخل ڪئي وئي آھي جنھن لاء رپورٽ جي ضرورت آھي، آخري ڏينھن کي حساب ۾ نه ورتو ويو آھي. اهو آهي، درخواست ۾ ڪٿي به نه هو <=، پر صرف <. مون کي ٻڌايو ويو ته هي ٽي ڪهاڻي پوائنٽس آهي، اهو آهي 3 ڏينهن.

ان کان پوء اسان:

• ڪهاڻي پوائنٽس جي درجه بندي سسٽم کي تبديل ڪيو ويو آهي. ھاڻي نابالغ غلطين لاءِ درست ڪيو ويو آھي جيڪي جلدي سسٽم ذريعي گذري سگھن ٿيون صارف تائين تيزيءَ سان پھچن ٿيون.
• اسان ڊولپمينٽ ۽ ٽيسٽ لاءِ لاڳاپيل ٽڪيٽن کي ملائڻ شروع ڪيو. اڳي، هر ٽڪيٽ، هر بگ هڪ بند ماحولياتي نظام هو، ڪنهن ٻئي سان ڳنڍيل نه هو. ھڪڙي صفحي تي ٽي بٽڻ تبديل ڪرڻ سان ٽي مختلف ٽڪيٽون ٿي سگھن ٿيون ٽن مختلف QA عملن جي بدران ھڪڙي خودڪار ٽيسٽ في صفحي جي.
• اسان ڊولپرز سان گڏ ڪم ڪرڻ شروع ڪيو مزدورن جي خرچن جو اندازو لڳائڻ لاءِ. هڪ بٽڻ کي تبديل ڪرڻ لاء ٽي ڏينهن مذاق نه آهي.

ڏهين ڏينهن

پهرين مهيني جي وچ ۾ ڪٿي، صورتحال ٿوري مستحڪم ٿي، مون سمجهيو ته بنيادي طور تي ڇا ٿي رهيو هو، ۽ اڳ ۾ ئي مستقبل ۾ ڏسڻ ۽ ڊگهي مدت جي حل بابت سوچڻ شروع ڪيو.

ڊگھي مدت جا مقصد:

• منظم پليٽ فارم. هر صفحي تي سوين درخواستون سنجيده نه آهن.
• متوقع رجحانات. وقتي ٽرئفڪ جون چوٽيون هيون جيڪي پهرين نظر ۾ ٻين ميٽرڪس سان لاڳاپو نه ٿيون رکن - اسان کي سمجهڻ جي ضرورت آهي ته ائين ڇو ٿيو ۽ اڳڪٿي ڪرڻ سکڻ.
• پليٽ فارم جي توسيع. ڪاروبار مسلسل وڌي رهيو آهي، وڌيڪ ۽ وڌيڪ صارفين اچي رهيا آهن، ۽ ٽرئفڪ وڌي رهي آهي.

ماضي ۾ اڪثر چيو ويندو هو: "اچو ته [ٻولي/ فريم ورڪ] ۾ هر شي کي ٻيهر لکون، سڀ ڪجهه بهتر ڪم ڪندو!"

اڪثر ڪيسن ۾ اهو ڪم نٿو ڪري، اهو سٺو آهي جيڪڏهن ٻيهر لکڻ ڪم ڪري ٿو. تنهن ڪري، اسان کي هڪ روڊ ميپ ٺاهڻ جي ضرورت آهي - هڪ مخصوص حڪمت عملي بيان ڪري ٿي ته ڪيئن ڪاروباري مقصد حاصل ڪيا ويندا (اسان ڇا ڪنداسين ۽ ڇو)، جيڪو:

• منصوبي جي مشن ۽ مقصدن کي ظاهر ڪري ٿو؛
• بنيادي مقصدن کي ترجيح ڏئي ٿو؛
• ان کي حاصل ڪرڻ لاء هڪ شيڊول تي مشتمل آهي.

ان کان اڳ، ڪنهن به ٽيم سان ڪنهن به تبديلي جي مقصد بابت نه ڳالهايو هو. اهو صحيح ڪاميابي جي ماپ جي ضرورت آهي. ڪمپني جي تاريخ ۾ پهريون ڀيرو، اسان ٽيڪنيڪل گروپ لاءِ KPIs مقرر ڪيو، ۽ اهي اشارا تنظيمي گروپن سان جڙيل هئا.

اهو آهي، تنظيمي KPIs جي حمايت ڪئي وئي آهي ٽيمن جي، ۽ ٽيم KPIs جي حمايت ڪئي وئي آهي انفرادي KPIs پاران. ٻي صورت ۾، جيڪڏهن ٽيڪنالاجي KPIs تنظيمي ماڻهن سان ٺهڪندڙ نه هجن، پوء هرڪو پاڻ تي ڪپڙي ڇڪيندو آهي.

مثال طور، هڪ تنظيمي KPIs نئين شين جي ذريعي مارڪيٽ شيئر وڌائي رهيو آهي.

توهان وڌيڪ نئين پروڊڪٽس حاصل ڪرڻ جي مقصد کي ڪيئن سپورٽ ڪري سگهو ٿا؟

• پهريون، اسان وڌيڪ وقت خرچ ڪرڻ چاهيون ٿا نئين شين کي ترقي ڪرڻ بدران خرابين کي درست ڪرڻ جي. اهو هڪ منطقي حل آهي جنهن کي ماپ ڪرڻ آسان آهي.
• ٻيو، اسان ٽرانزيڪشن جي مقدار ۾ واڌ جي حمايت ڪرڻ چاهيون ٿا، ڇاڪاڻ ته مارڪيٽ جو وڏو حصو، وڌيڪ صارفين ۽، مطابق، وڌيڪ ٽرئفڪ.

پوءِ انفرادي KPIs جن کي گروپ جي اندر عمل ۾ آڻي سگھجي ٿو، مثال طور، انھيءَ جاءِ تي ھوندو جتان مکيه خرابيون اچن ٿيون. جيڪڏهن توهان خاص طور تي هن حصي تي ڌيان ڏيو ٿا، توهان پڪ ڪري سگهو ٿا ته تمام گهٽ خرابيون آهن، ۽ پوء نئين پروڊڪٽس کي ترقي ڪرڻ ۽ ٻيهر تنظيمي KPIs جي حمايت لاء وقت وڌندو.

اهڙيء طرح، هر فيصلو، بشمول ٻيهر لکڻ وارو ڪوڊ، انهن مخصوص مقصدن جي حمايت ڪرڻ گهرجي جيڪي ڪمپني اسان لاء مقرر ڪيا آهن (تنظيمي ترقي، نيون خاصيتون، نوڪريون).

هن عمل جي دوران، هڪ دلچسپ ڳالهه سامهون آئي، جيڪا خبر نه رڳو ٽيڪنالاجي لاء، پر ڪمپني ۾ عام طور تي: سڀني ٽڪيٽن کي گهٽ ۾ گهٽ هڪ KPI تي ڌيان ڏيڻ گهرجي. اهو آهي، جيڪڏهن هڪ پراڊڪٽ چوي ٿو ته اهو هڪ نئين خاصيت ٺاهڻ چاهي ٿو، پهريون سوال پڇيو وڃي: "ڪي پي آئي هي خاصيت ڪهڙي مدد ڪري ٿي؟" جيڪڏهن نه، پوء معاف ڪجو - اهو هڪ غير ضروري خاصيت وانگر لڳي ٿو.

ڏينهن ٽيهه

مهيني جي آخر ۾، مون هڪ ٻيو نرالو دريافت ڪيو: منهنجي اوپس ٽيم تي ڪنهن به ڪڏهن به اهي معاهدا نه ڏٺا آهن جيڪي اسان گراهڪن سان داخل ڪيا آهن. توھان پڇي سگھو ٿا ڇو توھان کي رابطا ڏسڻ جي ضرورت آھي.

• پهريون، ڇاڪاڻ ته SLAs بيان ڪيل آهن معاهدي ۾.
• ٻيو، SLA سڀ مختلف آهن. هر گراهڪ پنهنجي ضرورتن سان آيو، ۽ سيلز ڊپارٽمينٽ بغير ڏسڻ جي دستخط ڪيو.

هڪ ٻيو دلچسپ nuance اهو آهي ته معاهدو هڪ وڏي ڪلائنٽ سان گڏ بيان ڪيو ويو آهي ته پليٽ فارم پاران سپورٽ ڪيل سڀني سافٽ ويئر ورزن کي لازمي طور تي n-1 هجڻ گهرجي، اهو آهي، جديد نسخو نه، پر حتمي هڪ.

اهو واضح آهي ته اسان n-1 کان ڪيترو پري هئاسين جيڪڏهن پليٽ فارم ColdFusion ۽ SQL Server 2008 تي ٻڌل هو، جيڪو هاڻي جولاء ۾ مڪمل طور تي سهڪار نه ڪيو ويو.

ڏينهن پنجٽيهه

ٻئي مهيني جي وچ ڌاري مون وٽ ويهڻ ۽ ڪرڻ لاءِ ڪافي وقت هو قدروهڪرونقشه مڪمل طور تي سڄي عمل لاء. اهي ضروري قدم آهن جن کي کڻڻ جي ضرورت آهي، هڪ پراڊڪٽ ٺاهڻ کان وٺي ان کي صارف تائين پهچائڻ تائين، ۽ انهن کي ممڪن حد تائين تفصيل سان بيان ڪرڻ جي ضرورت آهي.

توهان عمل کي ننڍن ٽڪرن ۾ ٽوڙيو ۽ ڏسو ته ڇا تمام گهڻو وقت وٺي رهيو آهي، ڇا بهتر ٿي سگهي ٿو، بهتر، وغيره. مثال طور، هڪ پراڊڪٽ جي درخواست کي گرومنگ ذريعي وڃڻ ۾ ڪيترو وقت لڳندو آهي، اها ٽڪيٽ ڪڏهن پهچي ٿي جيڪا ڊولپر وٺي سگهي ٿي، QA وغيره. تنهن ڪري توهان هر فرد جي قدم کي تفصيل سان ڏسو ۽ سوچيو ته ڇا بهتر ٿي سگهي ٿو.

جڏهن مون اهو ڪيو، ٻه شيون منهنجي نظر کي پڪڙيو:

• QA کان واپس ڊولپرز ڏانهن واپسي ٽڪيٽن جو وڏو سيڪڙو؛
• پل جي درخواست نظرثاني تمام ڊگهو ورتو.

مسئلو اهو هو ته اهي نتيجا هئا جهڙوڪ: اهو لڳي ٿو ته گهڻو وقت وٺندو، پر اسان کي پڪ ناهي ته ڪيترو وقت.

"توهان بهتر نه ٿا ڪري سگهو جيڪو توهان ماپ نه ٿا ڪري سگهو."

ڪيئن ثابت ڪجي ته مسئلو ڪيترو سنجيده آهي؟ ڇا اهو ڏينهن يا ڪلاڪ ضايع ڪري ٿو؟

هن کي ماپڻ لاءِ، اسان جيرا جي عمل ۾ ٻه قدم شامل ڪيا: ”ديو لاءِ تيار“ ۽ ”قائم لاءِ تيار“ اندازو ڪرڻ لاءِ ته هر ٽڪيٽ ڪيترو وقت انتظار ڪري ٿو ۽ ڪيترا ڀيرا ڪنهن خاص مرحلي تي واپس اچي ٿو.

اسان پڻ شامل ڪيو ”جائزو ۾“ اهو ڄاڻڻ لاءِ ته جائزو وٺڻ لاءِ سراسري طور ڪيتريون ٽڪيٽون آهن، ۽ ان مان توهان ناچ شروع ڪري سگهو ٿا. اسان وٽ سسٽم ميٽرڪ هئا، هاڻي اسان نئين ميٽرڪ شامل ڪيو ۽ ماپ ڪرڻ شروع ڪيو:

• عمل جي ڪارڪردگي: ڪارڪردگي ۽ منصوبابندي / پهچائڻ.
• عمل جي معيار: عيب جو تعداد، QA کان عيب.

اهو واقعي سمجهڻ ۾ مدد ڪري ٿو ته ڇا سٺو ٿي رهيو آهي ۽ ڇا سٺو ناهي.

پنجاهه ڏينهن

اهو سڀ ڪجهه، يقينا، سٺو ۽ دلچسپ آهي، پر ٻئي مهيني جي آخر ۾ ڪجهه ٿيو ته، اصول ۾، اڳڪٿي هئي، جيتوڻيڪ مون کي اهڙي پيماني جي اميد نه هئي. ماڻهن وڃڻ شروع ڪيو ڇاڪاڻ ته اعليٰ انتظاميا تبديل ٿي چڪي هئي. نوان ماڻهو انتظاميا ۾ آيا ۽ سڀ ڪجهه تبديل ڪرڻ لڳا، ۽ پراڻا ماڻهو ڇڏي ويا. ۽ عام طور تي هڪ ڪمپني ۾ جيڪو ڪيترن سالن کان پراڻي آهي، هرڪو دوست آهي ۽ هرڪو هڪ ٻئي کي ڄاڻي ٿو.

اها توقع هئي، پر برطرفي جي پيماني تي غير متوقع هئي. مثال طور، هڪ هفتي ۾ ٻن ٽيمن جي اڳواڻن هڪ ئي وقت پنهنجون استعيفيٰون پنهنجي آزاد مرضيءَ سان پيش ڪيون. تنهن ڪري، مون کي نه رڳو ٻين مسئلن جي باري ۾ وسارڻ گهرجي، پر ڌيان ڏيڻ هڪ ٽيم ٺاهڻ. اهو هڪ ڊگهو ۽ ڏکيو مسئلو آهي حل ڪرڻ، پر ان سان معاملو ڪرڻو پيو ڇو ته مان انهن ماڻهن کي بچائڻ چاهيان ٿو جيڪي باقي رهي (يا انهن مان گهڻا). اهو ضروري هو ته ڪنهن به حقيقت تي رد عمل ڪيو وڃي ته ٽيم ۾ حوصلا برقرار رکڻ لاء ماڻهو ڇڏي ويا.

نظريي ۾، اھو سٺو آھي: ھڪڙو نئون ماڻھو اچي ٿو جنھن وٽ مڪمل ڪارٽ بلينچ آھي، جيڪو ٽيم جي صلاحيتن جو جائزو وٺي سگھي ٿو ۽ عملي کي تبديل ڪري سگھي ٿو. حقيقت ۾، توهان صرف ڪيترن ئي سببن لاء نوان ماڻهو نه آڻي سگهو ٿا. توازن هميشه جي ضرورت آهي.

• پراڻي ۽ نئين. اسان کي پراڻن ماڻهن کي رکڻو پوندو جيڪي تبديل ڪري سگهن ۽ مشن جي حمايت ڪن. پر ساڳئي وقت، اسان کي نئين رت ۾ آڻڻ جي ضرورت آهي، اسان ان بابت ٿوري دير بعد ڳالهائينداسين.
• تجربو. مون سٺن جونيئرن سان تمام گھڻيون ڳالھيون ڪيون، جيڪي اسان سان گڏ ڪم ڪرڻ جا شوقين ھئا. پر مان انهن کي وٺي نه سگهيس ڇاڪاڻ ته اتي ڪافي سينيئر نه هئا جيڪي جونيئرن جي مدد ڪن ۽ انهن لاءِ سرپرست طور ڪم ڪن. ان لاءِ ضروري هو ته پهريان مٿين کي ڀرتي ڪيو وڃي ۽ پوءِ ئي نوجوانن کي.
• گاجر ۽ لٺ.

مون وٽ ان سوال جو سٺو جواب نه آهي ته صحيح توازن ڇا آهي، ان کي ڪيئن برقرار رکڻو آهي، ڪيترا ماڻهو رکڻ گهرجن ۽ ڪيترو زور ڏيڻو آهي. اهو هڪ خالص انفرادي عمل آهي.

ڏينهن پنجون

مون ٽيم کي ويجهي کان ڏسڻ شروع ڪيو ته مون کي سمجھڻ لاء ڪير هو، ۽ هڪ ڀيرو ٻيهر مون کي ياد آيو:

"گهڻا مسئلا ماڻهو مسئلا آهن."

مون ڏٺو آهي ته ٽيم جيئن ته - ٻئي ديو ۽ اوپس - ٽي وڏا مسئلا آهن:

• موجوده صورتحال تي اطمينان.
• ذميواري جي کوٽ - ڇاڪاڻ ته ڪو به ڪاروبار تي اثر انداز ڪرڻ لاءِ ڪارڪردگي جي ڪم جا نتيجا ڪڏهن به نه کڻي آيو آهي.
• تبديلي جو خوف.

تبديلي هميشه توهان کي توهان جي آرام واري علائقي مان ڪڍي ٿي، ۽ نوجوان ماڻهو آهن، وڌيڪ اهي تبديلي کي ناپسند ڪن ٿا ڇاڪاڻ ته اهي نه سمجھندا آهن ڇو ۽ اهي نه سمجھندا آهن ته ڪيئن. سڀ کان وڌيڪ عام جواب مون ٻڌو آهي، "اسان اهو ڪڏهن به نه ڪيو آهي." ان کان سواء، اهو مڪمل بيوقوفيت جي نقطي تي پهچي ويو آهي - معمولي تبديليون بغير ڪنهن جي ناراضگي کان سواء نه ٿي سگهي. ۽ ڪابه ڳالهه ڪيتري نه تبديلين انهن جي ڪم کي متاثر ڪيو، ماڻهن چيو: ”نه، ڇو؟ اهو ڪم نه ڪندو“.

پر توهان ڪجھ به تبديل ڪرڻ کان سواء بهتر نه ٿا ڪري سگهو.

مون هڪ ملازم سان بلڪل بيوقوف گفتگو ڪئي هئي، مون هن کي بهتر ڪرڻ لاء پنهنجا خيال ٻڌايو، جنهن تي هن مون کي ٻڌايو:
- اوه، توهان نه ڏٺو ته اسان گذريل سال ڇا ڪيو هو!
- پوءِ ڇا؟
"هاڻي اهو ان کان گهڻو بهتر آهي."
- پوء، اهو بهتر نه ٿي سگهي؟
- ڇا لاءِ؟

سٺو سوال - ڇو؟ اهو ڄڻ ته هاڻي ان کان بهتر آهي، پوء هر شيء ڪافي آهي. اها ذميواري جي کوٽ جي ڪري ٿي، جيڪا اصولن ۾ بلڪل عام آهي. جيئن مون چيو، ٽيڪنيڪل گروپ ٿورڙي پاسي تي هو. ڪمپني ايمان آندو ته اهي موجود هجڻ گهرجي، پر ڪو به معيار مقرر نه ڪيو. ٽيڪنيڪل سپورٽ ڪڏهن به SLA کي نه ڏٺو، تنهنڪري اهو گروپ لاء ڪافي "قبول" هو (۽ اهو مون کي تمام گهڻو متاثر ڪيو):

• 12 سيڪنڊ لوڊ ڪندي؛
• 5-10 منٽ هر ڇڏڻ جو وقت؛
• نازڪ مسئلن کي حل ڪرڻ ۾ ڏينهن ۽ هفتا لڳن ٿا؛
• ڊيوٽي اهلڪارن جي کوٽ 24x7 / ڪال تي.

ڪنهن به ڪڏهن اهو پڇڻ جي ڪوشش نه ڪئي آهي ته اسان ان کي بهتر ڇو نه ٿا ڪريون، ۽ ڪنهن به ڪڏهن محسوس نه ڪيو آهي ته اهو هن طريقي سان ٿيڻ جي ضرورت ناهي.

هڪ بونس طور، اتي هڪ وڌيڪ مسئلو هو: تجربي جي کوٽ. سينيئر ڇڏي ويا، ۽ باقي نوجوان ٽيم اڳئين راڄ هيٺ وڌيو ۽ ان کي زهر ڏنو ويو.

ان کان علاوه، ماڻهن کي ناڪام ٿيڻ ۽ نااهل ظاهر ٿيڻ جو خوف پڻ هو. اهو حقيقت ۾ ظاهر ڪيو ويو آهي ته، پهرين، اهي ڪنهن به حالت ۾ مدد لاء نه پڇيو. ڪيترا ڀيرا اسان هڪ گروپ ۽ انفرادي طور تي ڳالهايو آهي، ۽ مون چيو آهي، "هڪ سوال پڇو جيڪڏهن توهان کي خبر ناهي ته ڪجهه ڪيئن ڪجي." مان پاڻ تي يقين رکان ٿو ۽ ڄاڻان ٿو ته مان ڪنهن به مسئلي کي حل ڪري سگهان ٿو، پر اهو وقت وٺندو. تنهن ڪري، جيڪڏهن آئون ڪنهن کان پڇي سگهان ٿو جيڪو ڄاڻي ٿو ته ان کي 10 منٽن ۾ ڪيئن حل ڪجي، مان پڇندس. توهان وٽ جيترو گهٽ تجربو آهي، اوترو وڌيڪ توهان پڇڻ کان ڊڄندا آهيو ڇو ته توهان سوچيو ٿا ته توهان کي نااهل سمجهيو ويندو.

سوال پڇڻ جو هي خوف پاڻ کي دلچسپ طريقن سان ظاهر ڪري ٿو. مثال طور، توهان پڇو: "توهان هن ڪم سان ڪيئن پيا آهيو؟" - ”ڪجهه ڪلاڪ رهجي ويا آهن، مان پهريان ئي ختم ڪري رهيو آهيان. ٻئي ڏينهن وري پڇيائين ته جواب ملي ٿو ته سڀ ٺيڪ آهي، پر هڪڙو مسئلو هو، اهو ڏينهن جي آخر تائين ضرور تيار ٿي ويندو. ٻيو ڏينهن گذري ٿو، ۽ جيستائين توهان کي ڀت تي پڪڙيو وڃي ۽ ڪنهن سان ڳالهائڻ تي مجبور ڪيو وڃي، اهو جاري آهي. هڪ ماڻهو پاڻ ڪنهن مسئلي کي حل ڪرڻ چاهي ٿو؛ هو سمجهندو آهي ته جيڪڏهن هو پاڻ ان کي حل نه ڪندو ته اها وڏي ناڪامي هوندي.

اهو ڇو ٿو ڊولپرز تخميني کي وڌايو. اهو ساڳيو قصو هو، جڏهن اهي ڪنهن خاص ڪم تي بحث ڪري رهيا هئا، ته هنن مون کي اهڙو اهڃاڻ ڏنو، جو مان ڏاڍو حيران ٿي ويس. جنهن تي مون کي ٻڌايو ويو ته ڊولپر جي تخميني ۾، ڊولپر اهو وقت شامل ڪندو آهي ته ٽڪيٽ QA کان واپس ڪئي ويندي، ڇاڪاڻ ته اهي اتي غلطيون ڳوليندا، ۽ اهو وقت جيڪو پي آر وٺندو، ۽ اهو وقت جڏهن ماڻهن کي جائزو وٺڻ گهرجي. اھو مصروف ھوندو - اھو آھي، سڀ ڪجھ، جيڪو ممڪن آھي.

ٻيو، جيڪي ماڻهو نااهل ظاهر ٿيڻ کان ڊڄندا آهن overanalyze ڪرڻ. جڏهن توهان چئو ٿا ته ڇا واقعي ڪرڻ جي ضرورت آهي، اهو شروع ٿئي ٿو: "نه، ڇا جيڪڏهن اسان هتي ان بابت سوچيو؟" انهي لحاظ کان، اسان جي ڪمپني منفرد ناهي؛ اهو نوجوانن لاء هڪ معياري مسئلو آهي.

جواب ۾، مون هيٺ ڏنل طريقا متعارف ڪرايا:

• ضابطو 30 منٽ. جيڪڏهن توهان اڌ ڪلاڪ ۾ مسئلو حل نه ڪري سگهو، ڪنهن کي مدد لاء پڇو. اهو ڪم ڪاميابي جي مختلف درجي سان، ڇو ته ماڻهو اڃا تائين نه پڇندا آهن، پر گهٽ ۾ گهٽ عمل شروع ٿي چڪو آهي.
• هر شيء کي ختم ڪريو پر جوهر, ھڪڙي ڪم کي مڪمل ڪرڻ جي آخري حد جو اندازو لڳائڻ ۾، اھو آھي، صرف غور ڪريو ته اھو ڪوڊ لکڻ ۾ ڪيترو وقت وٺندو.
• مسلسل سکيا انهن لاء جيڪي overanalysis. اهو صرف ماڻهن سان مسلسل ڪم آهي.

ڇهين ڏينهن

جڏهن مان اهو سڀ ڪجهه ڪري رهيو هوس، اهو وقت هو بجيٽ جو اندازو لڳائڻ جو. يقينن، مون کي ڪيتريون ئي دلچسپ شيون مليون آهن جتي اسان پنهنجو پئسا خرچ ڪيو. مثال طور، اسان وٽ هڪ مڪمل ريڪ هڪ الڳ ڊيٽا سينٽر ۾ هڪ FTP سرور سان هو، جيڪو هڪ ڪلائنٽ طرفان استعمال ڪيو ويو هو. اهو ظاهر ٿيو ته "... اسان منتقل ٿي ويا، پر هو ائين ئي رهيو، اسان هن کي تبديل نه ڪيو." اهو 2 سال اڳ هو.

خاص دلچسپي جو بل ڪلائوڊ سروسز لاءِ هو. مان سمجهان ٿو ته اعلي ڪلائوڊ بل جو بنيادي سبب اهي ڊولپرز آهن جن جي زندگي ۾ پهريون ڀيرو سرور تائين لامحدود رسائي آهي. انهن کي پڇڻ جي ضرورت ناهي: ”مهرباني ڪري مون کي هڪ ٽيسٽ سرور ڏيو،“ اهي پاڻ وٺي ​​سگهن ٿا. ان سان گڏ، ڊولپرز هميشه هڪ بهترين سسٽم ٺاهڻ چاهيندا آهن ته فيسڪشن ۽ نيٽ فلڪس حسد ٿي ويندا.

پر ڊولپرز کي سرور خريد ڪرڻ ۾ تجربو ۽ سرور جي گهربل سائيز کي طئي ڪرڻ جي مهارت نه آهي، ڇاڪاڻ ته انهن کي اڳ ۾ ضرورت نه هئي. ۽ اهي عام طور تي ڪافي نه سمجھندا آهن فرق ۽ ڪارڪردگي جي وچ ۾ فرق.

لسٽ جا نتيجا:

• اسان ساڳيو ڊيٽا سينٽر ڇڏي ڏنو.
• اسان 3 لاگ سروسز سان معاهدو ختم ڪيو. ڇاڪاڻ ته اسان وٽ انهن مان 5 هئا - هر ڊولپر جيڪو ڪجهه سان کيڏڻ شروع ڪيو هڪ نئون ورتو.
• 7 AWS سسٽم بند ڪيا ويا. ٻيهر، ڪنهن به مئل منصوبن کي نه روڪيو؛ اهي سڀئي ڪم جاري رکيا.
• گھٽ ۾ گھٽ سافٽ ويئر جي قيمت 6 ڀيرا.

پنجويهه ڏينهن

وقت گذرندو ويو ۽ ٻن اڍائي مهينن ۾ مون کي بورڊ آف ڊائريڪٽرز سان ملڻو پيو. اسان جو بورڊ آف ڊائريڪٽرس ٻين کان بهتر يا بدتر ناهي؛ سڀني ڊائريڪٽرن جي بورڊن وانگر، اهو سڀ ڪجهه ڄاڻڻ چاهي ٿو. ماڻهو پئسو سيڙپ ڪن ٿا ۽ اهو سمجهڻ چاهين ٿا ته اسان جيڪي ڪندا آهيون سي ڪي پي آءِ جي سيٽ ۾ ڪيترو مناسب آهي.

ڊائريڪٽرن جو بورڊ هر مهيني تمام گهڻي معلومات حاصل ڪري ٿو: صارفين جو تعداد، انهن جي واڌ، اهي ڪهڙيون خدمتون استعمال ڪن ٿا ۽ ڪيئن، ڪارڪردگي ۽ پيداوار، ۽ آخرڪار، سراسري صفحي جي لوڊشيڊنگ جي رفتار.

صرف مسئلو اهو آهي ته مان سمجهان ٿو ته اوسط خالص برائي آهي. پر بورڊ آف ڊائريڪٽرز کي اها وضاحت ڪرڻ تمام ڏکيو آهي. اهي مجموعي نمبرن سان ڪم ڪرڻ جا عادي آهن، ۽ نه، مثال طور، في سيڪنڊ لوڊشيڊنگ جي وقت جي پکيڙ.

ان سلسلي ۾ ڪجهه دلچسپ نقطا هئا. مثال طور، مون چيو ته اسان کي مواد جي قسم جي لحاظ کان الڳ ويب سرورز جي وچ ۾ ٽرئفڪ کي ورهائڻ جي ضرورت آهي.

اهو آهي، ColdFusion Jetty ۽ nginx ذريعي وڃي ٿو ۽ صفحن کي لانچ ڪري ٿو. ۽ تصويرون، JS ۽ CSS هڪ الڳ نينڪس ذريعي انهن جي پنهنجي ترتيب سان. اھو ھڪڙو معياري عمل آھي جنھن بابت مان ڳالھائي رھيو آھيان لکيو ڪجهه سال اڳ. نتيجي طور، تصويرون تمام تيز لوڊ ڪنديون آهن، ۽... سراسري لوڊشيڊنگ جي رفتار 200 ms وڌي وئي آهي.

اهو ٿي چڪو آهي ڇاڪاڻ ته گراف ٺاهيو ويو آهي ڊيٽا جي بنياد تي جيڪو Jetty سان اچي ٿو. اهو آهي، فاسٽ مواد حساب ۾ شامل نه آهي - سراسري قدر جمپ ڪيو آهي. اها ڳالهه اسان لاءِ واضح هئي، اسان کلڻ لڳا، پر اسان بورڊ آف ڊائريڪٽرس کي ڪيئن سمجهائي سگهون ٿا ته اسان ڪجهه ڇو ڪيو ۽ شيون 12 سيڪڙو کان وڌيڪ خراب ٿي ويون؟

پنجويهه ڏينهن

ٽئين مهيني جي آخر ۾، مون محسوس ڪيو ته اتي هڪ شيء آهي جنهن تي مون ڪڏهن به ڳڻيو نه هو: وقت. هر شي بابت مون ڳالهايو وقت وٺندو آهي.

هي منهنجو حقيقي هفتيوار ڪئلينڊر آهي - صرف هڪ ڪم هفتي، تمام مصروف ناهي. هر شيء لاء ڪافي وقت نه آهي. تنهن ڪري، ٻيهر، توهان کي ماڻهن کي ڀرتي ڪرڻ جي ضرورت آهي جيڪي توهان جي مسئلن کي منهن ڏيڻ ۾ مدد ڪندا.

ٿڪل

اهو سڀ ڪجهه ناهي. هن ڪهاڻي ۾، ​​مون اڃا تائين حاصل نه ڪيو آهي ته اسان ڪيئن پراڊڪٽ سان ڪم ڪيو ۽ عام موج ۾ ٽيون ڪرڻ جي ڪوشش ڪئي، يا ڪيئن اسان ٽيڪنيڪل سپورٽ کي ضم ڪيو، يا اسان ٻين ٽيڪنيڪل مسئلن کي ڪيئن حل ڪيو. مثال طور، مون اتفاق سان ڪافي سکيو ته ڊيٽابيس ۾ سڀ کان وڏي ٽيبل تي اسان استعمال نٿا ڪريون SEQUENCE. اسان وٽ هڪ خود لکيل فعل آهي nextID، ۽ اهو هڪ ٽرانزيڪشن ۾ استعمال نه ڪيو ويو آهي.

اتي هڪ لک وڌيڪ اهڙيون شيون هيون جن بابت اسان گهڻي وقت تائين ڳالهائي سگهون ٿا. پر سڀ کان اهم شيء جيڪا اڃا تائين چوڻ جي ضرورت آهي اها ثقافت آهي.

اها ڪلچر آهي يا ان جو فقدان جيڪو ٻين سڀني مسئلن کي جنم ڏئي ٿو. اسان هڪ ثقافت ٺاهڻ جي ڪوشش ڪري رهيا آهيون جتي ماڻهو:

• ناڪامين کان نه ڊڄندا آھن؛
• غلطين مان سکو؛
• ٻين ٽيمن سان تعاون؛
• شروعات ڪرڻ؛
• ذميواري کڻڻ؛
• خوش آمديد نتيجو هڪ مقصد جي طور تي؛
• ڪاميابي جو جشن ملهائڻ.

ان سان ٻيو سڀ ڪجهه اچي ويندو.

ليون فائر Twitter تي, Facebook ۽ تي وچولي.

وراثت جي حوالي سان ٻه حڪمت عمليون آهن: ان سان هر قيمت تي ڪم ڪرڻ کان پاسو ڪريو، يا بهادريءَ سان لاڳاپيل مشڪلاتن تي قابو پائڻ. اسان ج DevOpsConf اسان ٻيو رستو وٺي رهيا آهيون، تبديل ٿيندڙ عمل ۽ طريقا. اسان سان شامل ٿيو يوٽيوب, ٽپال جي فهرست и ٽيليگرام، ۽ گڏجي اسين هڪ DevOps ڪلچر لاڳو ڪنداسين.

جو ذريعو: www.habr.com