توسعه دهندگان از مریخ هستند، مدیران از ونوس هستند

تصادفات تصادفی هستند و در واقع در سیاره ای دیگر بود...

من می خواهم سه داستان موفقیت و شکست را در مورد نحوه عملکرد یک توسعه دهنده باطن در یک تیم با مدیران به اشتراک بگذارم.

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

+ تمام قدرت در دستان شماست.
+ نیازی به التماس از کسی برای دسترسی به سرور نیست.
+ زمان واکنش سریع در همه جهات.
+ مهارت ها را به خوبی بهبود می بخشد.
+ درک کاملی از معماری محصول داشته باشید.

- مسئولیت بالا
- خطر شکستن تولید.
- متخصص خوب بودن در همه زمینه ها دشوار است.

علاقه ای ندارم، بیایید ادامه دهیم

داستان دوم.
شرکت بزرگ، پروژه بزرگ. یک بخش اداری با 5-7 کارمند و چندین گروه توسعه وجود دارد. وقتی برای کار در چنین شرکتی می آیید، هر مدیری فکر می کند که شما به اینجا نیامده اید تا روی یک محصول کار کنید، بلکه برای شکستن چیزی به اینجا آمده اید. نه NDA امضا شده و نه انتخاب در مصاحبه چیز دیگری را نشان نمی دهد. نه، این مرد با دستان کوچک کثیفش به اینجا آمده تا تولید بوسیدن ما را خراب کند. بنابراین، با چنین شخصی به حداقل ارتباط نیاز دارید؛ حداقل می توانید در پاسخ یک برچسب بیندازید. به سوالات مربوط به معماری پروژه پاسخ ندهید. توصیه می شود تا زمانی که سرپرست تیم درخواست نکند، اجازه دسترسی ندهید. و هنگامی که درخواست کند، با امتیازات کمتری از آنچه خواسته اند، پس خواهد داد. تقریباً تمام ارتباطات با چنین ادمین هایی توسط سیاهچاله بین بخش توسعه و بخش مدیریت جذب می شود. حل مسائل به سرعت غیرممکن است. اما شما نمی توانید حضوری بیایید - ادمین ها بیش از حد 24/7 مشغول هستند. (همیشه مشغول چه کاری هستید؟) برخی از ویژگی های عملکرد:

• میانگین زمان استقرار در تولید 4-5 ساعت است
• حداکثر زمان استقرار در تولید 9 ساعت
• برای یک توسعه دهنده، یک برنامه در حال تولید یک جعبه سیاه است، درست مانند خود سرور تولید. در کل چند نفر هستند؟
• کیفیت پایین انتشار، خطاهای مکرر
• توسعه دهنده در فرآیند انتشار شرکت نمی کند

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

قانون 1. مدیر نامرئی است.
روز انتشار، برنامه‌نویس و مدیر با هم ارتباط برقرار نمی‌کنند. ادمین سوالی نداره اما بعدا میفهمی چرا ادمین فردی اصولی است، پیام رسان ندارد، شماره تلفن خود را به کسی نمی دهد و پروفایلی در شبکه های اجتماعی ندارد. حتی یک عکس از او در هیچ کجا نیست، شما چه شکلی هستید رفیق؟ ما حدود 15 دقیقه با مدیر مسئول در گیج می نشینیم و سعی می کنیم با این وویجر 1 ارتباط برقرار کنیم، سپس پیامی در ایمیل شرکت ظاهر می شود که او تمام کرده است. آیا قرار است از طریق پست مکاتبه کنیم؟ چرا که نه؟ راحت است، اینطور نیست؟ خوب، بیا خنک شویم. این روند در حال انجام است، هیچ بازگشتی وجود ندارد. دوباره پیام را بخوانید. "من تمام کردم". چی تموم کردی جایی که؟ کجا باید دنبالت بگردم؟ در اینجا متوجه می شوید که چرا 4 ساعت برای انتشار طبیعی است. ما یک شوک توسعه دریافت می کنیم، اما انتشار را تمام می کنیم. دیگر تمایلی برای رهایی وجود ندارد.

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

قانون 3، کوتاه
بلیط فوری، عملکرد کلیدی برای یکی از کاربران در حال تولید کار نمی کند. ما چند ساعتی را صرف چک کردن و چک کردن می کنیم. در یک محیط توسعه، همه چیز کار می کند. درک روشنی وجود دارد که ایده خوبی است که به گزارش های php-fpm نگاه کنید. در آن زمان هیچ سیستم log مانند ELK یا Prometheus در پروژه وجود نداشت. ما یک بلیط به بخش مدیریت باز می کنیم تا آنها به گزارش های php-fpm در سرور دسترسی داشته باشند. در اینجا باید بدانید که ما به دلیلی درخواست دسترسی داریم، آیا یادتان نیست که سیاه‌چاله و ادمین‌ها مشغول 24/7 هستند؟ اگر از آنها بخواهید که خود به سیاهه‌ها نگاه کنند، این کار با اولویت «در این زندگی نیست» است. بلیط ایجاد شد، ما یک پاسخ فوری از رئیس بخش مدیریت دریافت کردیم: "شما نباید به گزارش های تولید دسترسی داشته باشید، بدون اشکال بنویسید." پرده.

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

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

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

ما چه کرده ایم؟
برای هر نسخه، فهرستی از یادداشت‌های انتشار تولید می‌شد که شامل فهرستی از کارهایی بود که باید روی سرور انجام شود تا نسخه بعدی کار کند. این فهرست شامل چندین بخش بود، کاری که باید توسط مدیر، شخص مسئول انتشار و توسعه دهنده انجام شود. توسعه دهندگان دسترسی غیر ریشه ای به تمام سرورهای تولیدی دریافت کردند که باعث افزایش سرعت توسعه به طور کلی و حل مشکلات به طور خاص شد. توسعه دهندگان همچنین می دانند که تولید چگونه کار می کند، به چه خدماتی تقسیم می شود، کجا و چقدر هزینه کپی دارد. برخی از بارهای رزمی واضح تر شده اند که بدون شک بر کیفیت کد تأثیر می گذارد. ارتباط در طول فرآیند انتشار در چت یکی از پیام رسان های فوری صورت گرفت. اولاً ما فهرستی از همه اقدامات داشتیم و ثانیاً ارتباط در یک محیط نزدیکتر صورت می گرفت. داشتن سابقه اقدامات بیش از یک بار به کارکنان جدید اجازه داده است تا مشکلات را سریعتر حل کنند. این یک پارادوکس است، اما این اغلب به خود مدیران کمک می کند. من متعهد نمی شوم که با اطمینان بگویم، اما به نظر من مدیران شروع به درک بیشتر نحوه عملکرد پروژه و نحوه نگارش آن کرده اند. حتی گاهی اوقات برخی از جزئیات را با یکدیگر در میان می گذاشتیم. میانگین زمان انتشار به یک ساعت کاهش یافته است. گاهی اوقات ما در 30-40 دقیقه تمام می شدیم. تعداد باگ ها به طور قابل توجهی کاهش یافته است، اگر نه ده برابر. البته عوامل دیگری مانند تست های خودکار نیز در کاهش زمان انتشار موثر بودند. پس از هر انتشار، ما شروع به انجام بررسی های گذشته کردیم. به طوری که کل تیم ایده ای از چیزهای جدید، آنچه تغییر کرده و حذف شده است داشته باشد. متاسفانه همیشه ادمین ها سراغشون نمی اومدن، خب ادمین ها سرشون شلوغه... بی شک رضایت شغلی من به عنوان توسعه دهنده بیشتر شده. زمانی که بتوانید تقریباً هر مشکلی را که در حوزه صلاحیت شما است به سرعت حل کنید، احساس می کنید در بالاترین سطح قرار دارید. بعداً متوجه خواهم شد که تا حدودی ما یک فرهنگ توسعه را معرفی کردیم، البته نه به طور کامل، اما حتی آن شروع تحول نیز چشمگیر بود.

داستان سه
استارت آپ. یک مدیر، بخش توسعه کوچک. به محض ورود من یک صفر کامل هستم، زیرا ... من به هیچ جا به جز از طریق ایمیل دسترسی ندارم. ما به ادمین می نویسیم و درخواست دسترسی می کنیم. علاوه بر این، اطلاعاتی وجود دارد که او از کارمند جدید و نیاز به صدور لاگین / رمز عبور آگاه است. آنها از مخزن و VPN دسترسی دارند. چرا به ویکی، شهر تیمی، میز کار دسترسی داشته باشید؟ چیزهای بی فایده برای شخصی که برای نوشتن کل قسمت باطن فراخوانده شده است. فقط با گذشت زمان به برخی ابزارها دسترسی پیدا می کنیم. ورود البته با بی اعتمادی همراه بود. من سعی می‌کنم از طریق چت‌ها و سوالات اصلی به آرامی درک کنم که زیرساخت پروژه چگونه کار می‌کند. اساساً من چیزی را تشخیص نمی دهم. تولید همان جعبه سیاه قبلی است. اما بیشتر از آن، حتی سرورهای مرحله ای که برای آزمایش استفاده می شوند، یک جعبه سیاه هستند. ما نمی توانیم کاری انجام دهیم جز اینکه یک شاخه از Git را در آنجا مستقر کنیم. ما همچنین نمی توانیم برنامه خود را مانند فایل های env پیکربندی کنیم. دسترسی برای چنین عملیاتی داده نمی شود. شما باید التماس کنید که یک خط در پیکربندی برنامه خود در سرور تست تغییر کند. (تئوری وجود دارد مبنی بر اینکه برای ادمین ها حیاتی است که خود را در پروژه مهم بدانند؛ اگر از آنها خواسته نشود خطوط را در تنظیمات تغییر دهند، به سادگی نیازی به آنها نخواهد بود). خوب، مثل همیشه، راحت نیست؟ این به سرعت خسته کننده می شود، پس از گفتگوی مستقیم با ادمین متوجه می شویم که توسعه دهندگان برای نوشتن کد بد به دنیا آمده اند، طبیعتاً افراد ناتوانی هستند و بهتر است آنها را از تولید دور نگه دارید. اما در اینجا نیز از سرورهای آزمایشی، فقط در مورد. درگیری به سرعت در حال افزایش است. هیچ ارتباطی با ادمین وجود ندارد. تنها بودن او اوضاع را تشدید می کند. تصویر زیر یک تصویر معمولی است. رهایی. عملکرد خاصی کار نمی کند. زمان زیادی طول می‌کشد تا بفهمیم چه اتفاقی می‌افتد، ایده‌های مختلفی از توسعه‌دهندگان وارد چت می‌شود، اما ادمین در چنین شرایطی معمولاً توسعه‌دهندگان را مقصر فرض می‌کند. بعد تو چت مینویسه صبر کن اصلاحش کردم. وقتی از ما خواسته می شود که داستانی را با اطلاعاتی در مورد مشکل به جا بگذاریم، بهانه های سمی دریافت می کنیم. مثلاً بینی خود را جایی که جایش نیست نچسبانید. توسعه دهندگان باید کد بنویسند. شرایطی که بسیاری از حرکات بدن در یک پروژه از طریق یک نفر انجام می شود و فقط او می تواند عملیات مورد نیاز همه را انجام دهد بسیار ناراحت کننده است. چنین فردی یک گلوگاه وحشتناک است. اگر ایده‌های Devops برای کاهش زمان ورود به بازار تلاش می‌کنند، پس چنین افرادی بدترین دشمن ایده‌های Devops هستند. متأسفانه پرده اینجا بسته می شود.

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

منبع: www.habr.com