من اخیراً در DevOpsForum 2019 که توسط Logrocon میزبانی شده بود شرکت کردم. در این کنفرانس شرکت کنندگان سعی در یافتن راه حل ها و ابزارهای جدید برای تعامل موثر بین کسب و کار و توسعه و متخصصان خدمات فناوری اطلاعات داشتند.
کنفرانس موفقیت آمیز بود: واقعاً گزارش های مفید زیادی، فرمت های ارائه جالب و ارتباط زیادی با سخنرانان وجود داشت. و به خصوص مهم است که هیچ کس سعی نکرد چیزی به من بفروشد، چیزی که اخیراً سخنرانان کنفرانس های بزرگ مقصر آن بوده اند.
گزیده ای از سخنرانی های Raiffeisenbank، Alfastrakhovanie، تجربه Mango Telecom در پیاده سازی اتوماسیون و سایر جزئیات زیر برش.
نام من یانا است، من به عنوان تستر کار می کنم، اتوماسیون و همچنین DevOps را انجام می دهم و عاشق شرکت در کنفرانس ها و جلسات هستم. در دو سال گذشته، من در کنفرانس‌های Oleg Bunin (HighLoad++، TeamLead Conf)، رویدادهای Jug (Heisenbug، JPoint)، TestCon Moscow، DevOps Pro Moscow، Big Data Moscow بوده‌ام.
اول از همه توجه را به برنامه کنفرانس جلب می کنم. من کمتر به آنچه گزارش خواهد شد نگاه می کنم و بیشتر به سخنران. حتی اگر گزارش بسیار فنی و جالب باشد، این یک واقعیت نیست که بتوانید برخی از بهترین شیوه های گزارش را در شرکت خود اعمال کنید. و سپس به یک بلندگو نیاز دارید.
نور در انتهای خط لوله در Raiffeisenbank
معمولاً در حاشیه‌هایی که برایم جالب است به دنبال بلندگو می‌گردم. در DevOpsForum 2019، سخنران Raiffeisenbank، Mikhail Bizhan، توجه من را جلب کرد. در طول سخنرانی خود، او در مورد اینکه چگونه آنها به تدریج تیم خود را به DevOps متصل می کنند، چرا آنها به آن نیاز دارند و چگونه می توان ایده تبدیل DevOps را به تجارت بفروشد، صحبت کرد. خوب، به طور کلی، من در مورد چگونگی دیدن نور در انتهای خط لوله صحبت کردم.
میخائیل بیژن، مدیر اتوماسیون در Raiffeisenbank
اکنون آنها "DevOps" در شرکت خود ندارند. یعنی کار می کند اما نه در همه تیم ها. هنگام پیاده سازی DevOps، هم از نظر مهندسین خاص و هم از نظر نیاز محصول و بلوغ پلتفرمی که این محصول بر روی آن ساخته شده است، به آمادگی تیم ها متکی هستند. میشا گفت که چگونه به یک تجارت توضیح دهیم که چرا DevOps نیاز است.
بخش بانکی دارای چندین محرک رشد است: هزینه خدمات و گسترش پایگاه مشتری. افزایش هزینه خدمات محرک چندان خوبی نیست، اما رشد پایگاه مشتری برعکس است. اگر رقبا یک محصول به طور عینی جالب عرضه کنند، همه مشتریان به آنجا می روند، سپس به مرور زمان بازار به سطح می رسد. بنابراین، معرفی محصولات جدید به بازار و سرعت معرفی آنها، اصلی ترین موردی است که بانک ها روی آن تمرکز دارند. این دقیقاً همان چیزی است که DevOps برای آن است و کسب و کارها این را درک می کنند.
نکته مهم بعدی: DevOps همیشه زمان ورود به بازار را کاهش نمی دهد. DevOps به تنهایی نمی تواند کار کند، فقط بخشی از فرآیند ایجاد و ارائه یک محصول به بازار از توسعه تا تولید (از کد به مشتری) است. اما همه چیز قبل از کد مستقیماً به DevOps مربوط نمی شود. یعنی بازاریاب ها می توانند سال ها بازار را مطالعه کنند و تمام عمر خود را صرف عقب افتادن رقبا کنند. باید به سرعت درک کرد که مشتری به چه چیزی نیاز دارد و برای اجرای این یا آن ویژگی برنامه ریزی کرد - اغلب این چیزی است که برای کار DevOps و شرکت برای رسیدن به هدف خود کافی نیست. بنابراین، اول از همه، Raiffeisenbank با تجارت موافقت کرد که یادگیری نحوه استفاده از DevOps ضروری است. اتوماسیون به خاطر اتوماسیون کمک چندانی به مبارزه برای مشتریان جدید نخواهد کرد.
به طور کلی، میشا معتقد است که DevOps باید پیاده سازی شود، اما عاقلانه. و ما باید برای این واقعیت آماده باشیم که در ابتدای تحول بهره وری تیم کاهش می یابد ، درآمد کمتری کسب می کند ، اما پس از آن توجیه می شود.
اتوماسیون تست در Mango Telecom
یک گزارش جالب دیگر برای من به عنوان یک تستر توسط Egor Maslov از Mango Telecom ارائه شده است. این ارائه "اتوماسیون چرخه تست کامل در یک تیم SCRUM" نام داشت. Egor معتقد است که DevOps به طور خاص برای SCRUM ایجاد شده است، اما در عین حال، معرفی DevOps به یک تیم SCRUM کاملاً مشکل ساز است. این به این دلیل اتفاق می‌افتد که تیم SCRUM همیشه در جایی در حال اجرا است، زمانی برای حواس‌پرت شدن با نوآوری‌ها و بازسازی فرآیند وجود ندارد. مشکل همچنین در این واقعیت نهفته است که SCRUM شامل جداسازی تیم‌های فرعی در تیم (تیم آزمایش، تیم توسعه و غیره) نمی‌شود. خوب، علاوه بر این، برای خودکار کردن یک فرآیند موجود، به مستندات نیاز است، و در SCRUM، اغلب هیچ مستندی به طور کامل وجود ندارد - "محصول مهمتر از نوعی نوشتن است."
پس از تغییر به SCRUM، آزمایش‌کنندگان شروع به مشورت با توسعه‌دهندگان در مورد نحوه آزمایش ویژگی‌ها کردند. به تدریج حجم کارکردها افزایش یافت، هیچ مستندی وجود نداشت و آنها شروع به کشف اشکالات زیادی در عملکرد کردند که تحت آزمایش نبود و به طور کلی دیگر مشخص نبود چه کسی و چه زمانی آن را آزمایش کرده است. به طور خلاصه - سردرگمی و نوسان. ما تصمیم گرفتیم به تست اتوماسیون روی بیاوریم. اما حتی در آن زمان نیز یک شکست کامل وجود داشت. آنها متخصصان اتوماسیون برون سپاری را استخدام کردند که در پشته ای ناشناخته برای آزمایش کنندگان داخلی می نوشتند. چارچوب تست‌های خودکار البته کار می‌کرد، اما پس از خروج برون‌سپاری‌ها، دو هفته به طول انجامید. تلاش بعدی برای معرفی تست خودکار شماره دو بود. با این واقعیت شروع شد که همه چیز باید در داخل شرکت ساخته شود، به تنهایی (بردار مناسب: ایجاد تخصص در داخل)، در چارچوب SCRUM، و مستندسازی در این فرآیند ایجاد شود. پشته برای اتوماسیون باید با پشته محصول برابر باشد (در اینجا من آن را اضافه می کنم، پروژه جاوا اسکریپت خود را با هیچ چیز دیگری آزمایش نکنید). در پایان دوی سرعت، آنها نمایشی از نحوه عملکرد خودکار تست با کل تیم انجام دادند (مفید). بنابراین، مشارکت همه اعضای تیم در فرآیند اتوماسیون افزایش یافت، همچنین اعتماد به تست‌های خودکار و احتمال استفاده از این تست خودکار (و به دلیل شکست‌های مداوم تا یک ماه دیگر اظهار نظر نمی‌شود) افزایش یافت.
به هر حال، در DevOpsForum 2019 یک میکروفون باز وجود داشت - یک قالب شناخته شده و به نظر من مفید از سخنرانی ها. شما به این صورت راه می‌روید، به گزارش‌ها گوش می‌دهید، و سپس تصمیم می‌گیرید که در کنفرانس ارزش بحث کردن درباره موضوع یا مشکل خاصی را دارد و تجربیات مربوطه را در حل مشکل به اشتراک می‌گذارید.
همچنین متوجه شدم که برگزارکنندگان گزارش‌های کوتاهی تهیه کردند. هر گزارش بیش از 10 دقیقه طول نمی کشد و به دنبال آن سوالاتی وجود دارد. به این ترتیب می توانید موضوعات زیادی را به طور همزمان پوشش دهید و از سخنرانان مورد علاقه خود سؤال بپرسید.
بین ارائه ها، در غرفه های شرکای کنفرانس قدم زدم و چیزهای زیادی دزدیدم/برنده شدم. اوه، من عاشق جزوه هستم!
میز گرد و مشکلات DevOps با مدیر توسعه در Alfastrakhovanie
نقطه جوش کیک DevOpsForum 2019 برای من جلسه عمومی یک ساعته با کارشناسان DevOps بود. از چهار شرکت‌کننده جلسه دعوت شد تا از زوایای مختلف به DevOps نگاه کنند: آنتون ایسانین (Alfastrakhovanie، مدیر توسعه)، Nailya Zamashkina (آزمایشگاه Fintech، مدیر عامل)، اولگ اگورکین (Rostelecom، مربی چابک) و Anton Martyanov (کارشناس مستقل، DevOps را بررسی کرد. از نقطه نظر تجاری).
کارشناسان نزدیکتر به مردم نشستند و سپس اتفاقات شروع شد: برای یک ساعت کامل، شرکت‌کنندگان از حضار سؤالات خود را مطرح کردند و کارشناسان رپ را گرفتند. گاهی اوقات بحث های واقعی پیش می آمد. سؤالات بسیار متفاوت بود، به عنوان مثال: آیا اصلاً به مهندسان DevOps نیاز است، چرا نمی توان آنها را به عنوان مدیران سیستم آموزش داد، آیا باید DevOps به همه ارائه شود، ارزش آن چیست و غیره.
سپس شخصا با آنتون آیسانین صحبت کردم. ما در مورد نیاز به آوردن فرهنگ DevOps به هر خانه بحث کردیم و جنبه تاریک تحول DevOps را آشکار کردیم.
بیایید تصور کنیم که همه دور هم جمع شدند و تصمیم گرفتند که DevOps هم برای محصول و هم برای تجارت و تیم مورد نیاز است. بیا بریم اجراش کنیم همه چیز درست شد. نفس را بیرون دادیم. DevOps ما را به مشتری نزدیکتر کرده است، اکنون می توانیم به سرعت تمام خواسته های او را برآورده کنیم. در نتیجه، ما یک بخش عملیات بزرگ با مقررات و الزامات سخت‌گیرانه داریم و دائماً نقص‌هایی در محصول پیدا می‌کند و درخواست‌های زیادی ایجاد می‌کند. علاوه بر این، به همه نقص ها وضعیت "فوری" اختصاص داده می شود، حتی اگر مشتری به طور غیرمنتظره ای بخواهد دکمه را به جای سبز رنگ زرد کند. پروژه در حال رشد است، تعداد نسخه ها در حال افزایش است و بر این اساس، تعداد نقص ها و سوء تفاهم ها از عملکرد جدید توسط مشتریان. Ops 10 نفر دیگر را استخدام می کند تا از ایرادات گزارش دهی عقب نمانند و توسعه 15 نفر دیگر را استخدام می کند تا از بسته شدن آنها جلوگیری کند. و به جای معرفی ویژگی‌های جدید، تیم با SD بی‌پایان کار می‌کند و عملکرد و پشتیبانی را به کاربر توضیح می‌دهد. در نتیجه، هم Ops و هم توسعه کار می‌کنند، اما مشتری و کسب‌وکار ناراضی هستند: ویژگی‌های جدید گیر می‌کنند. به نظر می رسد که DevOps وجود دارد، اما به نظر نمی رسد وجود داشته باشد.
با توجه به نیاز به پیاده سازی DevOps، آنتون به وضوح بیان کرد که این به طور مستقیم به مقیاس کسب و کار بستگی دارد. اگر سرویس دهی به یک مشتری در سال یک میلیارد برای شرکت به ارمغان بیاورد، DevOps مورد نیاز نیست (به شرطی که نیازی به ایجاد تغییرات جدید در این مشتری به طور منظم نداشته باشید). همه چیز با شکلات پوشیده شده است. اما اگر تجارت رشد کرد و مشتریان بیشتری ظاهر شدند، باید رعایت کنید. به عنوان یک قاعده، در ابتدا هیچ عملیات جالبی در شرکت وجود ندارد. ابتدا محصول را قطع می کنیم و تنها پس از آن متوجه می شویم که برای اینکه محصول کار کند، باید مراقب سرورها و نظارت بر منابع باشیم. این زمانی است که Ops به وجود می آید. باید درک کرد که Ops، به عنوان یک بخش جداگانه، شروع به ایجاد یک سری موانع برای توسعه خواهد کرد و همه تحویل ها متوقف خواهند شد. یعنی در این مورد، فرهنگ DevOps از قبل مرتبط است، اما ما نباید جنبه تاریک آن را فراموش کنیم.
منبع: www.habr.com