ما داریم صحبت می کنیم، البته، در مورد . اگر وارد جزئیات نمی‌شوید، در 30 سپتامبر و 1 اکتبر کنفرانسی را در مورد ترکیب فرآیندهای توسعه، آزمایش و عملیات برگزار می‌کنیم، و اگر وارد جزئیات می‌شوید، لطفاً تحت cat.
به عنوان بخشی از رویکرد DevOps، تمام بخش‌های توسعه فناوری یک پروژه در هم تنیده شده‌اند، به‌طور موازی اتفاق می‌افتند و بر یکدیگر تأثیر می‌گذارند. از اهمیت ویژه ای در اینجا ایجاد فرآیندهای توسعه خودکار است که می توانند در زمان واقعی تغییر، شبیه سازی و آزمایش شوند. این به شما کمک می کند تا فوراً به تغییرات بازار پاسخ دهید.
در کنفرانس می خواهیم نشان دهیم که چگونه این رویکرد بر توسعه محصول تأثیر می گذارد. چگونه قابلیت اطمینان و سازگاری سیستم برای مشتری تضمین می شود. چگونه DevOps ساختار و رویکرد یک شرکت را برای سازماندهی فرآیند کاری خود تغییر می دهد.
پشت صحنه
برای ما مهم است که نه تنها بدانیم شرکت‌های مختلف در چارچوب رویکرد DevOps چه می‌کنند، بلکه بدانیم چرا همه این‌ها انجام می‌شود. بنابراین، ما نه تنها از کارشناسان دعوت کردیم تا به کمیته برنامه بپیوندند، بلکه از متخصصانی که گفتمان DevOps را از موقعیت های مختلف می بینند، دعوت کردیم:
- مهندسین ارشد؛
- توسعه دهندگان؛
- تیم رهبری می کند؛
- CTO.
از یک طرف، این امر باعث ایجاد مشکلات و درگیری در هنگام بحث در مورد درخواست های گزارش می شود. اگر یک مهندس علاقه مند به تجزیه و تحلیل یک حادثه بزرگ است، پس برای یک توسعه دهنده مهم تر است که بفهمد چگونه نرم افزاری را ایجاد کند که در ابرها و زیرساخت ها کار کند. اما با توافق، برنامه ای ایجاد می کنیم که برای همه ارزشمند و جالب خواهد بود: از مهندسان تا CTO.
هدف کنفرانس ما فقط انتخاب بیشترین گزارش‌های تبلیغاتی نیست، بلکه ارائه تصویر کلی است: رویکرد DevOps در عمل چگونه کار می‌کند، هنگام حرکت به فرآیندهای جدید، می‌توانید با چه نوع رنک‌هایی مواجه شوید. در همان زمان، ما بخش محتوا را ایجاد می کنیم و از مشکل کسب و کار به فناوری های خاص فرو می رویم.
بخش های کنفرانس مانند قبل باقی خواهد ماند .
- پلت فرم زیرساخت.
- زیرساخت به عنوان کد
- تحویل مستمر.
- بازخورد.
- معماری در DevOps، DevOps برای CTO.
- شیوه های SRE.
- آموزش و مدیریت دانش.
- امنیت، DevSecOps.
- تبدیل DevOps
فراخوان مقالات: به دنبال چه نوع گزارش هایی هستیم
ما به طور مشروط مخاطبان بالقوه کنفرانس را به پنج گروه تقسیم کردیم: مهندسان، توسعه دهندگان، متخصصان امنیتی، رهبران تیم و CTO. هر گروه انگیزه خود را برای حضور در کنفرانس دارد. و اگر از این موقعیت ها به DevOps نگاه کنید، می توانید درک کنید که چگونه موضوع خود را متمرکز کنید و کجا باید تأکید کنید.
برای مهندسان، کسانی که در حال ایجاد یک پلت فرم زیرساخت هستند، درک روندهای موجود مهم است تا بفهمیم کدام فناوری ها در حال حاضر پیشرفته ترین هستند. آنها علاقه مند به یادگیری تجربیات واقعی در استفاده از این فناوری ها و تبادل نظر خواهند بود. یک مهندس از شنیدن گزارشی در مورد تجزیه و تحلیل برخی تصادفات سخت خوشحال خواهد شد و ما نیز به نوبه خود سعی خواهیم کرد چنین گزارشی را انتخاب و بررسی کنیم.
برای توسعه دهندگان درک چنین مفهومی مهم است برنامه بومی ابری. یعنی چگونه نرم افزار را طوری توسعه دهیم که در ابرها و زیرساخت های مختلف کار کند. توسعه دهنده باید دائماً از نرم افزار بازخورد دریافت کند. در اینجا می‌خواهیم مواردی در مورد نحوه ساخت این فرآیند توسط شرکت‌ها، نحوه نظارت بر عملکرد نرم‌افزار و نحوه عملکرد کل فرآیند تحویل بشنویم.
متخصصان امنیت سایبری درک نحوه تنظیم فرآیند امنیتی به گونه ای که فرآیندهای توسعه و تغییر در شرکت را متوقف نکند، مهم است. موضوعات مربوط به الزاماتی که DevOps برای چنین متخصصانی قرار می دهد نیز جالب خواهد بود.
رهبران تیم می خواهند بدانند، فرآیند تحویل مداوم در سایر شرکت ها چگونه کار می کند. شرکت‌ها چه مسیری را برای رسیدن به این هدف طی کردند، چگونه فرآیندهای توسعه و تضمین کیفیت را در DevOps ایجاد کردند. رهبران تیم نیز به Cloud native علاقه دارند. و همچنین سوالاتی در مورد تعامل درون تیم و بین تیم های توسعه و مهندسی.
برای CTO مهمترین چیز این است که بفهمیم چگونه می توان همه این فرآیندها را به هم متصل کرد و آنها را با نیازهای تجاری تنظیم کرد. او مطمئن می شود که برنامه هم برای کسب و کار و هم برای مشتری قابل اعتماد است. و در اینجا باید درک کنید که چه فناوری هایی برای کدام وظایف تجاری کار می کنند، چگونه کل فرآیند را بسازید و غیره. CTO همچنین مسئول بودجه بندی است. به عنوان مثال، او باید بفهمد که چقدر باید برای آموزش مجدد متخصصان هزینه شود تا بتوانند در DevOps کار کنند.
اگر در این موارد حرفی برای گفتن دارید، ساکت ننشینید، . آخرین مهلت فراخوان مقالات 20 آگوست است. هرچه زودتر ثبت نام کنید، زمان بیشتری برای نهایی کردن گزارش و آماده شدن برای ارائه خود خواهید داشت. پس معطل نکنید
خوب، اگر نیازی به صحبت عمومی ندارید، فقط و در 30 شهریور و 1 مهر برای ارتباط با همکاران تشریف بیاورید. ما قول می دهیم که جالب و الهام بخش خواهد بود.
چگونه DevOps را می بینیم
برای اینکه دقیقاً منظور ما از DevOps چیست، توصیه می کنم گزارش من را بخوانید (یا دوباره بخوانید)." با قدم زدن در امواج بازار، مشاهده کردم که چگونه ایده DevOps در شرکت‌های با اندازه‌های مختلف تغییر می‌کند: از یک استارت‌آپ کوچک تا شرکت‌های چند ملیتی. این گزارش بر اساس یک سری سوالات ساخته شده است، با پاسخ دادن به آنها می توانید متوجه شوید که آیا شرکت شما به سمت DevOps حرکت می کند یا در جایی مشکلاتی وجود دارد.
DevOps یک سیستم پیچیده است، باید شامل موارد زیر باشد:
- محصول دیجیتال.
- ماژول های تجاری که این محصول دیجیتال را توسعه می دهند.
- تیم های محصول که کد می نویسند.
- شیوه های تحویل مستمر
- پلتفرم ها به عنوان یک سرویس
- زیرساخت به عنوان یک خدمت
- زیرساخت به عنوان کد
- روش های جداگانه برای حفظ قابلیت اطمینان، ساخته شده در DevOps.
- یک تمرین بازخوردی که همه آن را توصیف می کند.
در پایان گزارش نموداری وجود دارد که ایده ای از سیستم DevOps در شرکت ارائه می دهد. این به شما این امکان را می دهد که ببینید کدام فرآیندها در شرکت شما قبلاً ساده شده اند و کدام ها هنوز ساخته نشده اند.
فیلم گزارش را می توانید مشاهده کنید .
و اکنون یک جایزه وجود خواهد داشت: چندین ویدیو از RIT++ 2019 که به کلی ترین مسائل تحول DevOps می پردازد.
زیرساخت های شرکت به عنوان یک محصول
Artyom Naumenko تیم DevOps را در Skyeng رهبری می کند و از توسعه زیرساخت های شرکت خود مراقبت می کند. او به چگونگی تأثیر زیرساخت بر فرآیندهای تجاری در SkyEng گفت: چگونه می توان بازگشت سرمایه را برای آن محاسبه کرد، چه معیارهایی را باید برای محاسبه انتخاب کرد و چگونه برای بهبود آنها کار کرد.
در مسیر میکروسرویس ها
شرکت Nixys از پروژه های پرمشغله وب و سیستم های توزیع شده پشتیبانی می کند. مدیر فنی آن، بوریس ارشوف، نحوه ترجمه محصولات نرم افزاری را که توسعه آن از 5 سال پیش (یا حتی بیشتر) آغاز شد، بر روی یک پلت فرم مدرن توضیح داد.
به عنوان یک قاعده، چنین پروژه هایی دنیای خاصی هستند که در آن گوشه های تاریک و باستانی زیرساخت وجود دارد که مهندسان فعلی از آنها اطلاعی ندارند. و رویکردهای معماری و توسعه که زمانی انتخاب شده بودند قدیمی هستند و نمی توانند همان سرعت توسعه و انتشار نسخه های جدید را برای کسب و کار فراهم کنند. در نتیجه، هر عرضه محصول به یک ماجراجویی باورنکردنی تبدیل می‌شود، جایی که چیزی دائماً از بین می‌رود و در غیرمنتظره‌ترین مکان.
مدیران این گونه پروژه ها به ناچار با نیاز به دگرگونی تمامی فرآیندهای فناوری مواجه هستند. بوریس در گزارش خود گفت:
- نحوه انتخاب معماری مناسب برای پروژه و نظم بخشیدن به زیرساخت ها؛
- از چه ابزارهایی استفاده کنیم و در مسیر تحول با چه مشکلاتی مواجه می شویم.
- کار بعدی چیه.
اتوماسیون انتشار یا نحوه تحویل سریع و بدون درد
الکساندر کوروتکوف یکی از توسعه دهندگان پیشرو سیستم CI/CD در CIAN است. وی در مورد ابزارهای اتوماسیونی صحبت کرد که امکان بهبود کیفیت و کاهش 5 برابری زمان تحویل کد به تولید را فراهم کرد. اما چنین نتایجی تنها با اتوماسیون به دست نمی آمد، بنابراین اسکندر نیز به تغییرات در فرآیندهای توسعه توجه کرد.
حوادث چگونه به یادگیری شما کمک می کند؟
Alexey Kirpichnikov به مدت 5 سال است که DevOps و زیرساخت ها را در SKB Kontur پیاده سازی کرده است. در طول سه سال، تقریباً 1000 فکاپ با درجات مختلف حماسی در شرکت او اتفاق افتاد. در میان آنها، برای مثال، 36٪ به دلیل عرضه یک نسخه با کیفیت پایین به تولید، و 14٪ ناشی از کار تعمیر و نگهداری سخت افزار در مرکز داده است.
آرشیو گزارشات (پس از مرگ) که مهندسان این شرکت چندین سال متوالی نگهداری می کنند، دستیابی به چنین اطلاعات دقیقی را در مورد حوادث ممکن می سازد. پس از مرگ توسط مهندس وظیفه نوشته شده است که اولین کسی بود که به سیگنال اضطراری پاسخ داد و شروع به تعمیر همه چیز کرد. چرا مهندسانی را که شب ها با چهره پردازی دست و پنجه نرم می کنند با نوشتن گزارش عذاب می دهند؟ این داده ها به شما امکان می دهد کل تصویر را ببینید و توسعه زیرساخت ها را در جهت درست حرکت دهید.
الکسی در سخنرانی خود نحوه نوشتن یک پس از مرگ واقعا مفید و نحوه اجرای تمرین چنین گزارشاتی را در یک شرکت بزرگ به اشتراک گذاشت. اگر داستان هایی در مورد اینکه چگونه یک نفر خراب کرده است، دوست دارید، ویدیوی اجرا را تماشا کنید.
ما درک می کنیم که دیدگاه شما از DevOps ممکن است با دیدگاه ما مطابقت نداشته باشد. جالب است بدانید که تحول DevOps را چگونه می بینید. تجربه و دیدگاه خود را در مورد این موضوع در نظرات به اشتراک بگذارید.
چه گزارش هایی را قبلاً در برنامه پذیرفته ایم؟
این هفته کمیته برنامه 4 گزارش را تصویب کرد: در مورد امنیت، زیرساخت ها و اقدامات SRE.
شاید دردناک ترین موضوع تحول DevOps: چگونه مطمئن شویم که افراد بخش امنیت اطلاعات ارتباطات از قبل ایجاد شده بین توسعه، عملیات و مدیریت را از بین نبرند. برخی از شرکت ها بدون بخش امنیت اطلاعات مدیریت می کنند. چگونه امنیت اطلاعات را در این مورد تضمین کنیم؟ در مورد آن مونا آرکیپووا از sudo.su. از گزارش او می آموزیم:
- چه چیزی باید محافظت شود و از چه کسی؛
- فرآیندهای امنیتی معمول چیست؟
- نحوه تلاقی فرآیندهای فناوری اطلاعات و امنیت اطلاعات؛
- CIS CSC چیست و چگونه می توان آن را پیاده سازی کرد.
- چگونه و با چه شاخص هایی باید بررسی های منظم امنیت اطلاعات را انجام داد.
گزارش بعدی مربوط به توسعه زیرساخت به عنوان کد است. مقدار روتین دستی را کاهش دهید و کل پروژه را به آشوب تبدیل نکنید، آیا این امکان پذیر است؟ به این سوال ماکسیم کوستریکین از ایکستنز. شرکت او استفاده می کند Terraform برای کار با زیرساخت AWS. این ابزار راحت است، اما سوال این است که چگونه می توان از ایجاد یک بلوک بزرگ کد هنگام استفاده از آن جلوگیری کرد. نگهداری از چنین میراثی هر سال گرانتر می شود.
Maxim نحوه عملکرد الگوهای قرار دادن کد را با هدف ساده سازی اتوماسیون و توسعه نشان می دهد.
یکی دیگر از زیرساخت ها خواهیم شنید ولادیمیر ریابوف از Playkey. در اینجا ما در مورد پلت فرم زیرساخت صحبت خواهیم کرد و خواهیم آموخت:
- چگونه بفهمیم که آیا از فضای ذخیره سازی به طور موثر استفاده می شود.
- اگر تنها از 10 ترابایت فضای ذخیره سازی استفاده شود، چگونه صدها کاربر می توانند 20 ترابایت محتوا دریافت کنند.
- چگونه داده ها را 5 بار فشرده کنیم و در زمان واقعی در اختیار کاربران قرار دهیم.
- نحوه همگام سازی داده ها در پرواز بین چندین مرکز داده؛
- نحوه از بین بردن هرگونه تأثیر کاربران بر روی یکدیگر هنگام استفاده متوالی از یک ماشین مجازی.
راز این جادو در تکنولوژی است ZFS برای FreeBSD و چنگال تازه اش ZFS در لینوکس. ولادیمیر پرونده های Playkey را به اشتراک خواهد گذاشت.
Matvey Kukuy از Amixr.IO آماده با مثال هایی از زندگی ، چی SRE و چگونه به ساخت سیستم های قابل اعتماد کمک می کند. Amixr.IO حوادث مشتری را از طریق باطن خود عبور می دهد؛ ده ها تیم در حال انجام وظیفه در سراسر جهان تاکنون با 150 هزار پرونده برخورد کرده اند. در کنفرانس، Matvey آمار و بینش‌هایی را که شرکتش با حل مشکلات مشتری و تجزیه و تحلیل شکست‌ها جمع‌آوری کرده است، به اشتراک می‌گذارد.
یک بار دیگر از شما می خواهم که حریص نباشید و تجربه خود را به عنوان یک سامورایی DevOps به اشتراک بگذارید. خدمت برای یک گزارش، و من و شما 2,5 ماه فرصت داریم تا یک سخنرانی عالی آماده کنیم. اگر می خواهید شنونده باشید، با به‌روزرسانی‌های برنامه به خبرنامه بروید و به طور جدی به فکر رزرو بلیط از قبل باشید، زیرا نزدیک به تاریخ کنفرانس گرانتر می‌شوند.
منبع: www.habr.com