تصادفونه تصادفي دي، او په حقیقت کې دا په بل سیارټ کې وه ...
زه غواړم درې د بریا او ناکامۍ کیسې شریک کړم چې څنګه د بیک انډ پراختیا کونکي په ټیم کې د مدیرانو سره کار کوي.
یوه کیسه.
ویب سټوډیو، د کارمندانو شمیر په یو لاس سره شمیرل کیدی شي. نن تاسو د ترتیب ډیزاینر یاست، سبا تاسو ملاتړ کوونکی یاست، بله ورځ تاسو مدیر یاست. له یوې خوا، تاسو کولی شئ خورا ښه تجربه ترلاسه کړئ. له بلې خوا، په ټولو برخو کې د وړتیا نشتوالی شتون لري. زه اوس هم د کار لومړۍ ورځ په یاد لرم، زه لاهم شنه یم، مالک وايي: "پرانیزي،" مګر زه نه پوهیږم چې دا څه دي. د مدیرانو سره اړیکه خارج شوې ده، ځکه تاسو پخپله یو مدیر یاست. راځئ چې د دې وضعیت ګټې او زیانونه په پام کې ونیسو.
+ ټول ځواک ستاسو په لاس کې دی.
+ سرور ته د لاسرسي لپاره له چا څخه بخښنه غوښتلو ته اړتیا نشته.
+ په ټولو لارښوونو کې د ګړندي عکس العمل وخت.
+ مهارتونه ښه وده کوي.
+ د محصول جوړښت بشپړ پوهه ولرئ.
- لوړ مسؤلیت.
- د تولید د ماتیدو خطر.
- دا ستونزمنه ده چې په ټولو برخو کې یو ښه متخصص وي.
علاقه نه لري، راځئ چې پرمخ لاړ شو
دویمه کیسه.
لوی شرکت، لویه پروژه. د ادارې څانګه شتون لري چې 5-7 کارمندان او ډیری پرمختیایي ډلې لري. کله چې تاسو په داسې شرکت کې کار کولو ته راشئ، نو هر مدیر فکر کوي چې تاسو دلته د یو محصول کار کولو لپاره نه یاست، بلکې د یو څه ماتولو لپاره راغلی یاست. نه لاسلیک شوی NDA او نه هم په مرکه کې انتخاب بل ډول اشاره کوي. نه، دا سړی دلته د خپلو ناوړو کوچنیو لاسونو سره راغلی ترڅو زموږ د بوسو تولید خراب کړي. له همدې امله، د داسې یو کس سره تاسو لږترلږه اړیکو ته اړتیا لرئ؛ لږترلږه، تاسو کولی شئ په ځواب کې یو سټیکر وغورځوئ. د پروژې د جوړښت په اړه پوښتنو ته ځواب مه ورکوئ. دا مشوره ورکول کیږي تر څو چې د ټیم مشر غوښتنه ونه کړي لاسرسی مه ورکوئ. او کله چې هغه وغواړي، هغه به یې د دوی په پرتله د لږو امتیازاتو سره بیرته ورکړي. د دې ډول مدیرانو سره نږدې ټولې اړیکې د پراختیا ریاست او اداري څانګې ترمینځ د تور سوراخ لخوا جذب کیږي. دا ناشونې ده چې ستونزې په چټکۍ سره حل شي. مګر تاسو نشئ کولی په شخص کې راشي - مدیران 24/7 ډیر بوخت دي. (تاسو هر وخت څه کوئ؟) د فعالیت ځینې ځانګړتیاوې:
- په تولید کې د ځای پرځای کولو اوسط وخت 4-5 ساعته دی
- په تولید کې د ځای پرځای کولو اعظمي وخت 9 ساعته
- د پراختیا کونکي لپاره ، په تولید کې غوښتنلیک یو تور بکس دی ، لکه د تولید سرور پخپله. په مجموع کې څو دي؟
- د خپرونو ټیټ کیفیت، پرله پسې تېروتنې
- پراختیا کونکی د خوشې کولو پروسې کې برخه نه اخلي
ښه، ما څه تمه درلوده، البته، نوي خلک تولید ته اجازه نه لري. ښه، ښه، د صبر ترلاسه کولو سره، موږ د نورو باور ترلاسه کول پیل کوو. مګر د ځینو دلیلونو لپاره، شیان د مدیرانو سره دومره ساده ندي.
1. اډمین پټ دی.
د خوشې کولو ورځ، پراختیا کونکي او مدیر اړیکه نه نیسي. مدیر هیڅ پوښتنه نلري. مګر تاسو پوهیږئ چې ولې وروسته. اډمین یو اصولي شخص دی، میسینجر نه لري، د خپل تلیفون شمیره هیچا ته نه ورکوي، او په ټولنیزو شبکو کې پروفایل نلري. په هر ځای کې د هغه عکس هم نشته، ته څه ښکاري یاره؟ موږ د مسؤل مدیر سره شاوخوا 15 دقیقې په حیرانتیا کې ناست یو، هڅه کوو چې د دې وایجر 1 سره اړیکه ټینګه کړو، بیا د کارپوریټ بریښنالیک کې یو پیغام څرګندیږي چې هغه پای ته رسیدلی. ایا موږ به د بریښنالیک له لارې اړیکه ونیسو؟ ولې نه؟ اسانه، نه دا؟ ښه، راځئ چې یخ کړو. پروسه لا دمخه روانه ده ، هیڅ شاته تګ نشته. پیغام بیا ولولئ. "ما ختم کړ". تا څه ختم کړل؟ چیرته؟ زه باید چیرته وګورم؟ دلته تاسو پوهیږئ چې ولې د خوشې کیدو لپاره 4 ساعته نورمال دي. موږ د پراختیا شاک ترلاسه کوو، مګر موږ خوشې کول پای ته ورسوو. نور د خلاصون هیڅ هیله نشته.
عمل 2. دا نسخه نه ده.
راتلونکی خپرونه. د تجربې ترلاسه کولو سره ، موږ د مدیرانو لپاره د سرور لپاره د اړین سافټویر او کتابتونونو لیست رامینځته کول پیل کوو ، د ځینو لپاره نسخې په ګوته کوي. د تل په څیر، موږ یو ضعیف راډیو سیګنال ترلاسه کوو چې مدیر هلته یو څه پای ته رسولي. د راجسټریشن ازموینه پیل کیږي ، کوم چې پخپله شاوخوا یو ساعت وخت نیسي. داسې بریښي چې هرڅه کار کوي ، مګر یو جدي ستونزه شتون لري. مهم فعالیت کار نه کوي. راتلونکی څو ساعته د تیمبورینونو سره نڅا کول، د کافي په میدانونو کې د قسمت ویل، او د کوډ هرې برخې تفصيلي بیاکتنه وه. اډمین وايي هر څه یې کړي دي. د کره شوي پراختیا کونکو لخوا لیکل شوی غوښتنلیک کار نه کوي ، مګر سرور کار کوي. د هغه لپاره کومه پوښتنه؟ د یو ساعت په پای کې ، موږ مدیر ترلاسه کوو چې د تولید سرور کې د کتابتون نسخه په چیٹ او بینګو کې واستوو - دا هغه څه ندي چې موږ ورته اړتیا لرو. موږ له مدیر څخه غوښتنه کوو چې اړین نسخه نصب کړي ، مګر په ځواب کې موږ ترلاسه کوو چې هغه د OS کڅوړې مدیر کې د دې نسخې نشتوالي له امله دا نشي کولی. دلته، د هغه د حافظې د رخصتیو څخه، مدیر په یاد لري چې بل مدیر لا دمخه دا ستونزه په ساده ډول د لاس په واسطه د اړتیا وړ نسخه راټولولو سره حل کړې وه. مګر نه، زموږ به دا کار ونه کړي. مقررات منع کوي. کارل، موږ دلته د څو ساعتونو لپاره ناست یو، د وخت حد څه دی؟! موږ یو بل شاک ترلاسه کوو او یو څه خوشې کول پای ته رسوو.
3 فعل، لنډ
عاجل ټکټ، کلیدي فعالیت په تولید کې د یو کاروونکو لپاره کار نه کوي. موږ څو ساعته په چک کولو او چک کولو تیر کړو. په پرمختیایي چاپیریال کې، هرڅه کار کوي. یو روښانه پوهه شتون لري چې دا به ښه نظر وي چې د php-fpm لاګونو ته وګورو. په هغه وخت کې په پروژه کې د ELK یا Prometheus په څیر د لاګ سیسټمونه شتون نلري. موږ د ادارې څانګې ته ټکټ خلاصوو ترڅو دوی په سرور کې د php-fpm لاګونو ته لاسرسی ورکړي. دلته تاسو اړتیا لرئ پوه شئ چې موږ د یو دلیل لپاره د لاسرسي غوښتنه کوو ، ایا تاسو د بلیک هول په اړه په یاد نه یاست او مدیران 24/7 بوخت دي؟ که تاسو له دوی څخه وپوښتئ چې پخپله لاګونه وګورئ، نو دا یو کار دی چې "په دې ژوند کې نه" لومړیتوب لري. ټیکټ رامینځته شو ، موږ د ادارې څانګې مشر څخه سمدستي ځواب ترلاسه کړ: "تاسو باید د تولید لاګونو ته لاسرسی ته اړتیا نلرئ ، پرته له کیچونو ولیکئ." یوه پرده.
عمل 4 او هاخوا
موږ لاهم په تولید کې لسګونه ستونزې راټولوو ، د کتابتونونو مختلف نسخو ، غیر ترتیب شوي سافټویر ، غیر چمتو شوي سرور بارونو او نورو ستونزو له امله. البته، د کوډ کیګونه هم شتون لري، موږ به د ټولو ګناهونو لپاره مدیران ملامت نه کړو، موږ به یوازې د دې پروژې لپاره یو بل عادي عملیات ذکر کړو. موږ د شالید ډیری کارګران درلودل چې د څارونکي له لارې پیل شوي، او ځینې سکریپټونه باید په کرون کې اضافه شي. کله ناکله ورته کارګرانو کار بند کړ. په کتار سرور کې بار د بریښنا په سرعت سره وده وکړه، او غمجن کاروونکي د څرخيدونکي لوډر ته ګوري. د دې کارګرانو ګړندي کولو لپاره ، دا بس و چې دوی بیا پیل کړئ ، مګر بیا ، یوازې یو مدیر دا کولی شي. پداسې حال کې چې دا ډول بنسټیز عملیات ترسره کیږي، ټوله ورځ تیریږي. دلته، البته، دا د یادولو وړ ده چې ګمراه شوي پروګرام کونکي باید کارګران ولیکي ترڅو دوی ټکر ونه کړي، مګر کله چې دوی سقوط وکړي، دا به ښه وي چې پوه شي چې ولې، کله ناکله تولید ته د لاسرسي نشتوالي له امله ناشونی وي. کورس، او د پایلې په توګه، د پراختیا کونکي څخه د لاګونو نشتوالی.
بدلون.
دا ټول د اوږدې مودې لپاره زغملو سره، د ټیم سره یوځای موږ یو داسې لوري ته حرکت پیل کړ چې زموږ لپاره ډیر بریالی و. د لنډیز لپاره، موږ له کومو ستونزو سره مخ یو؟
- د پراختیا کونکو او اداري څانګې ترمنځ د کیفیت د اړیکو نشتوالی
- مدیران، دا معلومه شوه (!)، په هیڅ ډول نه پوهیږي چې غوښتنلیک څنګه جوړ شوی، کوم انحصار لري او دا څنګه کار کوي.
- پراختیا کونکي نه پوهیږي چې د تولید چاپیریال څنګه کار کوي او په پایله کې نشي کولی په مؤثره توګه ستونزو ته ځواب ووایی.
- د ځای پرځای کولو پروسه خورا اوږده ده.
- بې ثباته خوشې کول.
موږ څه کړي دي؟
د هرې خوشې کولو لپاره، د ریلیز نوټونو لیست جوړ شوی و، چې پکې د کار لیست شامل و چې د کار کولو لپاره د راتلونکي خوشې کولو لپاره په سرور کې ترسره کولو ته اړتیا لري. په لیست کې ډیری برخې شاملې وې، هغه کار چې باید د مدیر، د خوشې کولو مسؤول شخص، او پراختیا کونکي لخوا ترسره شي. پراختیا کونکو ټولو تولید سرورونو ته غیر ریټ لاسرسی ترلاسه کړ ، کوم چې په عمومي ډول پرمختګ ګړندی کړی او په ځانګړي توګه د ستونزې حل کول. پراختیا کونکي پدې هم پوهه لري چې تولید څنګه کار کوي ، کوم خدمتونه ویشل شوي ، چیرې او څومره د نقلونو لګښت. ځینې جنګي بارونه روښانه شوي، کوم چې بې له شکه د کوډ کیفیت اغیزه کوي. د خوشې کولو پروسې په جریان کې اړیکه د یو فوري میسینجر په چیٹ کې ترسره شوه. لومړی، موږ د ټولو کړنو یوه نښه درلوده، او دویم، اړیکه په نږدې چاپیریال کې ترسره شوه. د کړنو تاریخ له یو ځل څخه ډیر نوي کارمندانو ته اجازه ورکوي چې ستونزې په چټکۍ سره حل کړي. دا یو تناقض دی، مګر دا ډیری وختونه پخپله د مدیرانو سره مرسته کوي. زه به د ډاډ لپاره و نه وایم، مګر داسې ښکاري چې مدیرانو په دې پوهیدل پیل کړي چې پروژه څنګه کار کوي او څنګه لیکل کیږي. ځینې وختونه موږ حتی یو بل سره ځینې توضیحات شریک کړل. د اوسط خوشې کولو وخت یو ساعت ته راټیټ شوی. ځینې وختونه موږ په 30-40 دقیقو کې ترسره شوي. د کیګونو شمیر د پام وړ کم شوی ، که لس چنده نه وي. البته، نور فکتورونه هم د خوشې کولو وخت کمولو اغیزه کړې، لکه د آټوټسټس. د هرې خوشې کیدو وروسته، موږ د بیرته ستنیدو ترسره کول پیل کړل. نو ټول ټیم د دې په اړه نظر لري چې څه نوي دي ، څه بدل شوي ، او څه لرې شوي. له بده مرغه، مدیران تل دوی ته نه راځي، ښه، اډمینان بوخت دي ... د پراختیا کونکي په توګه زما د دندې رضایت بې له شکه ډیر شوی. کله چې تاسو کولی شئ په چټکۍ سره نږدې هره ستونزه حل کړئ چې ستاسو د وړتیا په ساحه کې وي، تاسو په سر کې احساس کوئ. وروسته، زه به پوه شوم چې تر یوې اندازې پورې موږ د ډیوپس کلتور معرفي کړ، په بشپړه توګه نه، البته، مګر حتی د بدلون پیل اغیزمن و.
دریمه کیسه
پیلول. یو مدیر، د کوچني پراختیا څانګه. په راتګ سره زه یو بشپړ صفر یم، ځکه ... زه د بریښنالیک پرته بل چیرې لاسرسی نلرم. موږ مدیر ته لیکو او د لاسرسي غوښتنه کوو. سربیره پردې، داسې معلومات شتون لري چې هغه د نوي کارمند څخه خبر دی او د ننوتلو / پاسورډونو صادرولو اړتیا لري. دوی د ذخیره کولو او VPN څخه لاسرسی ورکوي. ولې ویکي، ټیم سیټي، رنډیسک ته لاسرسی ورکړئ؟ د هغه چا لپاره بې ګټې شیان چې د بشپړ شالید برخې لیکلو لپاره ویل شوي. یوازې د وخت په تیریدو سره موږ ځینې وسیلو ته لاسرسی ترلاسه کوو. راتګ، البته، د بې باورۍ سره مخ شو. زه هڅه کوم چې ورو ورو احساس وکړم چې څنګه د پروژې زیربنا د چیټونو او مخکښو پوښتنو له لارې کار کوي. اساسا زه هیڅ نه پیژنم. تولید د پخوا په څیر ورته تور بکس دی. مګر له دې څخه ډیر، حتی د مرحلې سرورونه چې د ازموینې لپاره کارول کیږي یو تور بکس دی. موږ د Git څخه د څانګې له ځای پرځای کولو پرته بل څه نشو کولی. موږ هم نشو کولی خپل غوښتنلیک د .env فایلونو په څیر تنظیم کړو. د دې ډول عملیاتو لپاره لاسرسی نه ورکول کیږي. تاسو باید غوښتنه وکړئ چې د ازموینې سرور کې ستاسو د غوښتنلیک په ترتیب کې بدل شوی کرښه ترلاسه کړئ. (یوه تیوري شتون لري چې دا د مدیرانو لپاره حیاتي ده چې ځان په پروژه کې مهم احساس کړي؛ که له دوی څخه په تشکیلاتو کې د لینونو بدلولو غوښتنه ونه شي ، نو دوی ته به اړتیا ونلري). ښه، د تل په څیر، دا اسانه نه ده؟ دا په چټکۍ سره ستړي کیږي، د مدیر سره د مستقیم خبرو اترو وروسته موږ پوهیږو چې پراختیا کونکي د خراب کوډ لیکلو لپاره زیږیدلي دي، د طبیعت له مخې بې کفایته اشخاص دي او دا غوره ده چې دوی د تولید څخه لرې وساتئ. مګر دلته هم د ازموینې سرورونو څخه ، یوازې په قضیه کې. شخړه په چټکۍ سره مخ په زیاتیدو ده. د مدیر سره هیڅ اړیکه نشته. وضعیت د دې حقیقت له امله خراب شوی چې هغه یوازې دی. لاندې یو عادي انځور دی. خوشې کول. مشخص فعالیت کار نه کوي. دا موږ ته ډیر وخت نیسي ترڅو معلومه کړو چې څه پیښیږي ، د پراختیا کونکو مختلف نظرونه په چیٹ کې اچول کیږي ، مګر په داسې حالت کې مدیر معمولا داسې انګیري چې پراختیا کونکي ملامت دي. بیا یې په چیټ کې لیکي، انتظار وکړئ، ما هغه سم کړ. کله چې پوښتنه وشوه چې د ستونزې په اړه د معلوماتو سره یوه کیسه پریږدو، موږ زهرجن عذر ترلاسه کوو. لکه، خپله پوزه په هغه ځای کې مه پټوئ چې دا تړاو نلري. پراختیا کونکي باید کوډ ولیکي. هغه حالت چې په یوه پروژه کې د بدن ډیری حرکتونه د یو واحد شخص له لارې تیریږي او یوازې هغه د عملیاتو ترسره کولو ته لاسرسی لري چې هرڅوک ورته اړتیا لري خورا افسوسناک دی. دا ډول سړی یو لوی خنډ دی. که د Devops مفکورې هڅه کوي چې بازار ته وخت کم کړي، نو دا ډول خلک د Devops افکارو ترټولو بد دښمن دي. له بده مرغه دلته پرده وتړل شوه.
PS د خلکو سره په چیټونو کې د پراختیا کونکو vs اډمینونو په اړه لږ څه خبرو کولو وروسته ، ما له خلکو سره ولیدل چې زما درد یې شریک کړ. خو داسې کسان هم وو چې ویل یې چې دوی هېڅکله له داسې څه سره نه دي مخ شوي. په یوه ډیوپس کنفرانس کې ، ما له انتون ایزانین (الفا بانک) څخه وپوښتل چې دوی څنګه د مدیرانو په توګه د خنډ ستونزې سره معامله کوي ، کوم چې هغه وویل: "موږ دوی د بټونو سره بدل کړل." په ضمن کې د هغه ګډون سره. زه غواړم باور وکړم چې د دښمنانو په پرتله ډیر ښه مدیران شتون لري. او هو، په پیل کې انځور یو ریښتینی اړیکه ده.
سرچینه: www.habr.com