هفت کهن الگوی تبدیل بر اساس اصول DevOps

سوال "چگونه devops را پیاده سازی کنیم" سالهاست که مطرح بوده است، اما مواد خوب زیادی وجود ندارد. گاهی اوقات شما قربانی تبلیغات مشاوران نه چندان باهوشی می شوید که نیاز به فروش زمان خود دارند، مهم نیست چگونه. گاهی اوقات اینها کلمات مبهم و بسیار کلی در مورد نحوه شخم زدن کشتی های شرکت های بزرگ گستره های جهان است. این سوال پیش می آید: این برای ما چه اهمیتی دارد؟ نویسنده محترم، آیا می توانید ایده های خود را به وضوح در یک لیست فرموله کنید؟

همه اینها از این واقعیت ناشی می شود که تمرین و درک واقعی زیادی از نتیجه تحولات فرهنگ شرکت انباشته نشده است. تغییر فرهنگ چیزهای بلندمدتی است که نتایج آن در یک هفته یا یک ماه ظاهر نمی شود. ما به فردی مسن نیاز داریم که ببیند شرکت‌ها در طول سال‌ها چگونه ساخته شده‌اند و چگونه شکست خورده‌اند.

جان ویلیس - یکی از پدران DevOps. جان چندین دهه تجربه کار با تعداد زیادی از شرکت ها را دارد. اخیراً جان متوجه الگوهای خاصی شد که هنگام کار با هر یک از آنها اتفاق می افتد. با استفاده از این کهن الگوها، جان شرکت ها را در مسیر واقعی تحول DevOps راهنمایی می کند. درباره این کهن الگوها در ترجمه گزارش او از کنفرانس DevOops 2018 بیشتر بخوانید.

درباره گوینده:

بیش از 35 سال در مدیریت فناوری اطلاعات، در ایجاد سلف OpenCloud در Canonical شرکت کرد، در 10 استارتاپ شرکت کرد که دو مورد از آنها به Dell و Docker فروخته شد. در حال حاضر او معاون DevOps و Digital Practices در SJ Technologies است.

داستان بعدی از دیدگاه جان است.

نام من جان ویلیس است و راحت ترین مکان برای پیدا کردن من در توییتر است. @botchagalupe. من همان نام مستعار را در Gmail و GitHub دارم. آ این لینک می توانید فیلم های ضبط شده گزارش ها و ارائه های من را برای آنها پیدا کنید.

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

DevOps چیست؟

در واقع، اگر از 10 نفر مختلف بپرسید، آنها 10 پاسخ متفاوت خواهند داد. اما نکته جالب اینجاست: تمام این ده پاسخ صحیح خواهند بود. در اینجا هیچ پاسخ اشتباهی وجود ندارد. من تقریباً 10 سال در DevOps بودم و اولین آمریکایی در اولین DevOpsDay بودم. من نمی گویم که من از همه افرادی که در DevOps مشارکت دارند باهوش تر هستم، اما به ندرت کسی وجود دارد که تلاش زیادی برای آن انجام داده باشد. من معتقدم که DevOps زمانی اتفاق می‌افتد که سرمایه انسانی و فناوری با هم ترکیب شوند. ما اغلب بعد انسانی را فراموش می کنیم، اگرچه در مورد انواع فرهنگ ها زیاد صحبت می کنیم.

اکنون ما داده های زیادی داریم، پنج سال تحقیق آکادمیک، آزمایش تئوری ها در مقیاس صنعتی. آنچه این مطالعات به ما می گوید این است که اگر برخی از الگوهای رفتاری را در یک فرهنگ سازمانی ترکیب کنید، می توانید به 2000 برابر سرعت برسید. این شتاب با بهبود یکسانی در پایداری مطابقت دارد. این یک اندازه گیری کمی از مزایایی است که DevOps می تواند برای هر شرکتی به ارمغان بیاورد. چند سال پیش داشتم درباره DevOps با مدیر عامل یک شرکت Fortune 5000 صحبت می‌کردم. وقتی داشتم برای ارائه آماده می‌شدم، خیلی عصبی بودم زیرا باید سال‌ها تجربه‌ام را در 5 دقیقه خلاصه می‌کردم.

در پایان موارد زیر را عرض کردم تعریف DevOps: مجموعه ای از شیوه ها و الگوهایی است که امکان تبدیل سرمایه انسانی به سرمایه سازمانی با عملکرد بالا را فراهم می کند. به عنوان مثال روشی است که تویوتا در 50 یا 60 سال گذشته کار کرده است.

(از این پس، چنین نمودارهایی نه به عنوان ماده مرجع، بلکه به عنوان تصویر ارائه می شوند. محتوای آنها برای هر شرکت جدید متفاوت است. با این حال، تصویر را می توان به طور جداگانه مشاهده و بزرگ کرد. در این لینک.)

یکی از موفق ترین این شیوه ها این است نقشه برداری جریان ارزش. چندین کتاب خوب در این باره نوشته شده است که موفق ترین آنها اثر کارن مارتین است. اما در طول سال گذشته، به این نتیجه رسیدم که حتی این رویکرد نیز بسیار پیشرفته است. مطمئناً مزایای زیادی دارد و من بسیار از آن استفاده کرده ام. اما وقتی مدیر عامل از شما می‌پرسد که چرا شرکتش نمی‌تواند به ریل‌های جدید روی بیاورد، خیلی زود است که در مورد نقشه‌برداری جریان ارزش صحبت کنیم. سؤالات اساسی بسیار بیشتری وجود دارد که ابتدا باید به آنها پاسخ داده شود.

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

فرهنگ بد رویکردهای خوب را برای صبحانه می خورد

ایده اصلی این است: اگر فرهنگ سازمانی بد باشد، هیچ مقدار Lean، Agile، SAFE و DevOps کمکی نخواهد کرد. مانند غواصی در اعماق بدون تجهیزات غواصی یا کار بدون اشعه ایکس است. به عبارت دیگر، به تعبیر دراکر و دمینگ: یک فرهنگ سازمانی بد، هر سیستم خوبی را بدون خفه شدن در آن می بلعد.

برای حل این مشکل اصلی، باید مراحل زیر را انجام دهید:

1. همه کارها را قابل مشاهده کنید: شما باید همه کارها را قابل مشاهده کنید. نه به این معنا که لزوماً باید در یک صفحه نمایش داده شود، بلکه به این معنا که باید قابل مشاهده باشد.
2. سیستم های مدیریت کار تلفیقی: سیستم های مدیریتی باید یکپارچه شوند. در مسئله دانش «قبیله ای» و دانش نهادی، در 9 مورد از هر 10 مورد، گلوگاه مردم است. در کتاب "پروژه ققنوس" مشکل یک فرد مجرد به نام برنت بود که باعث شد پروژه سه سال از برنامه عقب بیفتد. و من همه جا با این "برنت ها" برخورد می کنم. برای رفع این تنگناها، از دو مورد بعدی در لیست خود استفاده می کنم.
3. روش شناسی نظریه محدودیت ها: نظریه محدودیت ها
4. هک های همکاری: هک های همکاری
5. تویوتا کاتا (مربیگری کاتا): من زیاد در مورد تویوتا کاتا صحبت نمی کنم. اگر علاقه مند هستید، در github من ارائه وجود دارد تقریباً در مورد هر یک از این موضوعات.
6. سازمان بازار گرا: سازمان بازارمحور
7. حسابرسان شیفت چپ: ممیزی در مراحل اولیه چرخه

من کار با یک سازمان را خیلی ساده شروع می کنم: به شرکت می روم و با کارمندان صحبت می کنم. همانطور که می بینید، هیچ فناوری بالایی وجود ندارد. تنها چیزی که نیاز دارید چیزی برای نوشتن است. من چندین تیم را در یک اتاق جمع می کنم و آنچه را که به من می گویند از منظر 7 کهن الگوی خود تجزیه و تحلیل می کنم. و بعد خودشان یک نشانگر به آنها می دهم و از آنها می خواهم تمام آنچه را که تا کنون با صدای بلند گفته اند روی تخته بنویسند. معمولا در این نوع جلسات یک نفر همه چیز را یادداشت می کند و در بهترین حالت می تواند 10 درصد بحث را یادداشت کند. با روش من می توان این رقم را به حدود 40 درصد رساند.

(این تصویر را می توان جداگانه مشاهده کرد لینک را ببینید)

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

یک گزینه کمی بهتر، گزینه ای با سطح بالایی از کنترل و صلاحیت است. اگر چنین شرکتی سودآور باشد، پس شاید به DevOps نیاز نداشته باشد. کار با شرکتی که دارای سطح کنترل بالا، شایستگی و همکاری پایین، اما در عین حال سطح بالایی از فرهنگ (تزکیه) است، بسیار جالب است. این به این معنی است که شرکت افراد زیادی دارد که دوست دارند در آنجا کار کنند و گردش کار کم است.

(این تصویر را می توان جداگانه مشاهده کرد لینک را ببینید)

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

تکرار می کنم، بدون تکنولوژی بالا. نشانگر سیاه واقعیت عینی نحوه کار همه چیز را به تصویر می کشد. با یک نشانگر قرمز، افراد آنچه را که در مورد وضعیت فعلی دوست ندارند علامت می‌زنند. مهم این است که آنها این را بنویسند نه من. وقتی بعد از جلسه ای به CIO می روم، لیستی از 10 موردی که باید اصلاح شوند را ارائه نمی دهم. من تلاش می کنم بین آنچه افراد شرکت می گویند و الگوهای اثبات شده موجود ارتباط پیدا کنم. در نهایت، یک نشانگر آبی راه حل های ممکن را برای مشکل پیشنهاد می کند.

(این تصویر را می توان جداگانه مشاهده کرد لینک را ببینید)

نمونه ای از این رویکرد اکنون در بالا نشان داده شده است. در ابتدای امسال با یک بانک کار کردم. افراد امنیتی در آنجا متقاعد شده بودند که نباید برای بررسی طراحی و الزامات بیایند.

(این تصویر را می توان جداگانه مشاهده کرد لینک را ببینید)

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

جلسه ما به شیوه ای بسیار گیج کننده پیش رفت: برای حدود سه ساعت، پنج تیم مختلف نتوانستند برای من توضیح دهند که بین کد و اسمبلی چه اتفاقی می افتد. و به نظر می رسد این ساده ترین چیز باشد. اکثر مشاوران DevOps از قبل فرض می کنند که همه از قبل این را می دانند.

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

(این تصویر را می توان جداگانه مشاهده کرد لینک را ببینید)

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

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

بنابراین، من از کارگران سؤال می کنم، آنها پاسخ ها را با نشانگرهای سه رنگ (مشکی، قرمز و آبی) یادداشت می کنند. من پاسخ های آنها را برای کهن الگوها تجزیه و تحلیل می کنم. حالا بیایید همه کهن الگوها را به ترتیب مورد بحث قرار دهیم.

1. Make All Work Visible: کار را قابل مشاهده کنید

اکثر شرکت هایی که با آنها کار می کنم درصد بسیار بالایی از کارهای ناشناخته دارند. به عنوان مثال، این زمانی است که یک کارمند به دیگری مراجعه می کند و به سادگی از شما می خواهد کاری انجام دهد. در سازمان های بزرگ، ممکن است 60 درصد کارهای برنامه ریزی نشده وجود داشته باشد. و تا 40 درصد کار به هیچ عنوان مستند نیست. اگر بوئینگ بود، دیگر در زندگی ام سوار هواپیمای آنها نمی شدم. اگر فقط نیمی از کار مستند باشد، معلوم نیست این کار به درستی انجام می شود یا خیر. تمام روش های دیگر بی فایده به نظر می رسند - هیچ فایده ای در تلاش برای خودکار کردن چیزی وجود ندارد، زیرا 50٪ شناخته شده ممکن است منسجم ترین و واضح ترین بخش کار باشد که اتوماسیون آن نتایج عالی را به همراه نخواهد داشت و از همه بدتر. چیزها در نیمه نامرئی قرار دارند. در غیاب مستندات، یافتن انواع هک ها و کارهای پنهان غیرممکن است، نه گلوگاه ها، همان «برنت هایی» که قبلاً در مورد آنها صحبت کردم. کتاب فوق العاده ای از دومینیکا دیگراندیس وجود دارد "مشاهده کردن کار". او فاش می کند پنج "نشت زمان" مختلف (دزدان زمان):

• کار بیش از حد در حال انجام (WIP)
• وابستگی های ناشناخته
• کار برنامه ریزی نشده
• اولویت های متناقض
• کار غفلت شده

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

The Phoenix Project یک داستان فوق العاده درباره پروژه ای است که سه سال دیر بود. یکی از شخصیت ها به همین دلیل با اخراج مواجه می شود و با شخصیت دیگری که به نوعی سقراط معرفی می شود ملاقات می کند. او کمک می کند تا بفهمیم دقیقا چه اشتباهی رخ داده است. معلوم می شود که این شرکت یک مدیر سیستم دارد که نامش برنت است و همه کارها به نوعی از طریق او انجام می شود. در یکی از جلسات از یکی از زیردستان می پرسند: چرا هر کار نیم ساعته یک هفته طول می کشد؟ پاسخ یک ارائه بسیار ساده از تئوری صف و قانون لیتل است و در این ارائه مشخص می شود که در 90 درصد اشغال، هر ساعت کار 9 ساعت طول می کشد. هر کار باید برای هفت نفر دیگر ارسال شود، به طوری که ساعت تبدیل به 63 ساعت می شود، 7 ضربدر 9. چیزی که من می گویم این است که برای استفاده از قانون لیتل یا هر نظریه صف پیچیده، حداقل باید داده داشته باشید.

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

وقتی کار قابل مشاهده است، داده ها را می توان به طور منظم طبقه بندی کرد (این کاری است که دومینیک در عکس انجام می دهد)، می توان انتزاع پنج نشت زمان را اعمال کرد، و اتوماسیون را می توان اعمال کرد.

2. ادغام سیستم های مدیریت کار: مدیریت وظیفه

کهن الگوهایی که من در مورد آنها صحبت می کنم نوعی هرم هستند. اگر اولی به درستی انجام شود، دومی قبلاً نوعی افزودنی است. بسیاری از اینها برای استارت آپ ها کار نمی کنند، آنها باید برای شرکت های بزرگتری مانند Fortune 5000 در نظر گرفته شوند. آخرین شرکتی که من برای آن کار کردم 10 سیستم فروش بلیط داشت. یک تیم Remedy داشت، تیمی دیگر نوعی از سیستم خود را نوشت، تیم سوم از Jira استفاده کردند و برخی به ایمیل بسنده کردند. اگر شرکت 30 خط لوله مختلف داشته باشد، همین مشکل پیش می‌آید، اما من وقت ندارم در مورد همه این موارد صحبت کنم.

من دقیقاً با مردم بحث می‌کنم که بلیط‌ها چگونه ایجاد می‌شوند، بعداً چه اتفاقی برای آنها می‌افتد و چگونه دور زده می‌شوند. جالب ترین چیز این است که مردم در جلسات ما کاملاً صمیمانه صحبت می کنند. از چند نفر پرسیدم که «تأثیر جزئی / بدون تأثیر» روی بلیط‌هایی که در واقع باید «تاثیر عمده» داشته باشند، می‌گذارند. معلوم شد که تقریباً همه این کار را می کنند. من وارد تقبیح نمی شوم و به هر طریق ممکن سعی می کنم افراد را شناسایی نکنم. وقتی آنها صادقانه چیزی را به من اعتراف می کنند، من آن شخص را نمی دهم. اما زمانی که تقریباً همه سیستم را دور می زنند، به این معنی است که تمام امنیت اساساً در پنجره پانسمان است. بنابراین نمی توان از داده های این سیستم نتیجه گیری کرد.

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

این امر در مورد تمام بخش ها از جمله زیرساخت ها و عملیات اعمال می شود. در این مورد، می توان حداقل یک ایده قابل قبول از وضعیت امور شکل داد. هنگامی که این فرآیند برقرار شد، ناگهان تشخیص اینکه چه کسی مسئول هر برنامه است آسان می شود. زیرا اکنون نه 50 درصد، بلکه 98 درصد خدمات جدید را دریافت می کنیم. اگر این فرآیند اصلی کار کند، دقت در سراسر سیستم بهبود می یابد.

خط لوله خدمات

این باز هم فقط برای شرکت های بزرگ صدق می کند. اگر شرکت جدیدی در زمینه جدیدی هستید، آستین ها را بالا بزنید و با Travis CI یا CircleCI خود کار کنید. وقتی صحبت از شرکت های Fortune 5000 به میان می آید، موردی که در بانکی که من در آن کار می کردم اتفاق افتاد. گوگل به سراغ آنها آمد و نمودارهایی از سیستم های قدیمی IBM به آنها نشان داده شد. بچه های گوگل با سردرگمی پرسیدند - کد منبع این کار کجاست؟ اما هیچ کد منبع، حتی یک رابط کاربری گرافیکی وجود ندارد. این واقعیتی است که سازمان های بزرگ باید با آن دست و پنجه نرم کنند: سوابق بانکی 40 ساله روی یک پردازنده مرکزی قدیمی. یکی از مشتریان من از ظروف Kubernetes با الگوهای Circuit Breaker، به علاوه Chaos Monkey، همه برای برنامه KeyBank استفاده می کند. اما این کانتینرها در نهایت به یک برنامه COBOL متصل می شوند.

بچه‌های گوگل کاملاً مطمئن بودند که تمام مشکلات مشتری من را حل خواهند کرد و سپس شروع به پرسیدن سؤال کردند: لوله داده IBM چیست؟ به آنها گفته می شود: این یک رابط است. به چی وصل میشه؟ به سیستم اسپری. و اون چیه؟ و غیره. در نگاه اول به نظر می رسد: چه نوع DevOps می تواند وجود داشته باشد؟ اما در واقع امکان پذیر است. سیستم های تحویل وجود دارد که به شما امکان می دهد گردش کار را به تیم های تحویل تحویل دهید.

3. نظریه محدودیت ها: نظریه محدودیت ها

بیایید به سراغ کهن الگوی سوم برویم: دانش نهادی/"قبیله ای". به عنوان یک قاعده، در هر سازمانی چندین نفر وجود دارند که همه چیز را می دانند و همه چیز را مدیریت می کنند. اینها کسانی هستند که طولانی ترین مدت در سازمان بوده اند و همه راه حل ها را می دانند.

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

برای حل این نوع مشکل می توانم برای مثال استفاده از Slack را پیشنهاد کنم. یک کارگردان باهوش خواهد پرسید - چرا؟ به طور معمول، در چنین مواردی، مشاوران DevOps پاسخ می دهند: زیرا همه این کار را انجام می دهند. اگر کارگردان واقعا باهوش باشد می گوید: پس چی. و اینجاست که دیالوگ به پایان می رسد. و پاسخ من به این است: زیرا چهار گلوگاه در شرکت وجود دارد، فرد، لو، سوزی و جین. برای نهادینه کردن دانش آنها، ابتدا باید Slack را معرفی کرد. همه ویکی های شما کاملا مزخرف هستند زیرا هیچ کس از وجود آنها خبر ندارد. اگر تیم مهندسی درگیر توسعه فرانت‌اند و بک‌اند است و همه باید بدانند که می‌توانند با تیم توسعه فرانت‌اند یا تیم زیرساخت با سؤالات تماس بگیرند. در آن زمان است که لو یا فرد احتمالاً زمان خواهند داشت تا به ویکی بپیوندند. و سپس در Slack ممکن است کسی بپرسد که چرا، مثلاً، مرحله 5 کار نمی کند. و سپس لو یا فرد دستورالعمل های ویکی را تصحیح می کنند. اگر این فرآیند را ایجاد کنید، بسیاری از چیزها خود به خود سر جای خود قرار می گیرند.

این نکته اصلی من است: برای توصیه به هر فناوری پیشرفته، ابتدا باید پایه و اساس آنها را مرتب کنید و این را می توان با راه حل های کم فناوری که قبلاً توضیح دادیم انجام داد. اگر با فن آوری های بالا شروع می کنید و توضیح نمی دهید که چرا آنها مورد نیاز هستند، به عنوان یک قاعده، این به خوبی ختم نمی شود. یکی از مشتریان ما از Azure ML، یک راه حل بسیار ارزان و ساده استفاده می کند. حدود 30 درصد از سوالات آنها توسط خود دستگاه خودآموز پاسخ داده شد. و این مورد توسط اپراتورهایی نوشته شده است که در علم داده، آمار یا ریاضیات درگیر نیستند. این قابل توجه است. هزینه چنین راه حلی حداقل است.

4. هک های همکاری: هک های همکاری

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

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

5. مربیگری کاتا

همانطور که در همان ابتدا هشدار دادم، امروز در این مورد صحبت نمی کنم. اگر علاقه مند هستید، می توانید نگاهی بیندازید برخی از ارائه های من.

همچنین صحبت خوبی در مورد این موضوع از مایک رادر وجود دارد:

6. بازارمحور: سازمان بازارمحور

در اینجا مشکلات مختلفی وجود دارد. به عنوان مثال، افراد "I"، افراد "T" و افراد "E". افراد "من" کسانی هستند که فقط یک کار را انجام می دهند. آنها معمولاً در سازمان هایی با بخش های مجزا وجود دارند. «ت» زمانی است که شخص در یک چیز خوب باشد اما در بعضی چیزها نیز خوب باشد. «ای» یا حتی «شانه» زمانی است که فرد مهارت های زیادی داشته باشد.

قانون کانوی در اینجا کار می کند (قانون کانوی) که در ساده ترین شکل می توان به صورت زیر بیان کرد: اگر سه تیم روی کامپایلر کار کنند، نتیجه یک کامپایلر از سه قسمت خواهد بود. بنابراین، اگر سطح بالایی از انزوا در یک سازمان وجود داشته باشد، حتی Kubernetes، Circuit breaker، توسعه پذیری API و سایر موارد فانتزی در این سازمان به همان شیوه خود سازمان چیده می شوند. اکیداً طبق گفته کانوی و به نکوهش همه شما گیک های جوان.

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

بسیاری از مردم این ساختار را به روش های مختلف توصیف می کنند، من از جمله بندی آن خوشم می آید ساخت/اجرای تیم ها، در آمازون به آن می گویند دو تیم پیتزا. در این ساختار، همه افراد تیپ «I» حول یک سرویس گروه بندی می شوند و به تدریج به نوع «T» نزدیک می شوند و در صورت وجود مدیریت صحیح، حتی می توانند به «E» تبدیل شوند. اولین استدلال مخالف در اینجا این است که چنین ساختاری دارای عناصر غیر ضروری است. اگر می توانید یک بخش ویژه از آزمایش کنندگان داشته باشید، چرا در هر بخش به یک آزمایش کننده نیاز دارید؟ که من پاسخ می دهم: هزینه های اضافی در این مورد قیمتی است که کل سازمان در آینده به نوع "E" تبدیل می شود. در این ساختار تستر به تدریج با شبکه ها، معماری، طراحی و ... آشنا می شود. در نتیجه هر شرکت کننده در سازمان از هر اتفاقی که در سازمان می افتد آگاهی کامل دارد. اگر می خواهید بدانید که این طرح در صنعت چگونه کار می کند، بخوانید مایک روتر، تویوتا کاتا.

7. حسابرسان شیفت چپ: حسابرسی در اوایل چرخه. رعایت قوانین ایمنی نمایش داده شده

این زمانی است که اعمال شما به اصطلاح، تست بویایی را پس نمی‌دهند. افرادی که برای شما کار می کنند احمق نیستند. اگر مانند مثال بالا، همه جا تاثیر جزئی/بدون تاثیر گذاشتند، این سه سال طول کشید و هیچ کس متوجه چیزی نشد، پس همه به خوبی می دانند که سیستم کار نمی کند. یا مثال دیگری - یک هیئت مشورتی تغییر، که در آن گزارش ها باید هر هفته، مثلاً چهارشنبه، ارائه شود. گروهی از افراد در آنجا کار می کنند (اتفاقاً حقوق چندانی ندارند) که در تئوری باید بدانند که سیستم به طور کلی چگونه کار می کند. و در طول پنج سال گذشته، احتمالاً متوجه شده اید که سیستم های ما بسیار پیچیده هستند. و پنج یا شش نفر باید در مورد تغییری که انجام نداده اند و در مورد آن چیزی نمی دانند تصمیم بگیرند.

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

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

طبق گزارش، که در سال 2018 توسط Sonatype ایجاد شد، 2017 میلیارد درخواست دانلود OSS در سال 87 وجود داشت.

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

نمونه ای از این دنباله:


این یک توصیه برای محصولات خاصی نیست، اگرچه من همه آنها را دوست دارم. من آنها را به عنوان مثال ذکر کردم تا نشان دهم که DevOps که در ابتدا مبتنی بر پارادایم سازمانی در صنعت بود، به شما امکان می‌دهد هر مرحله از کار را روی یک محصول خودکار کنید.

و دلیلی وجود ندارد که ما نتوانیم همان رویکرد امنیتی را در پیش بگیریم.

مجموع

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

لینک های مفید

در اینجا چند سخنرانی از کنفرانس DevOops وجود دارد که ممکن است برای شما مفید باشد:

• سرگئی بردنیکوف، آرتیوم کالیچکین - داستان موفقیت یا "Dev+DevOps+Ops" (تصویری, متن گزارش)
• باروخ سادوگورسکی، لئونید ایگولنیک - DevOps در مقیاس: تراژدی یونانی در سه پرده (تصویری, متن گزارش)
• الکساندر تیتوف، کریل تولکاچف - DevOps، مهندسان و جامعه
• تیموتی لیستر - شخصیت ها، جامعه و فرهنگ: عوامل مهم برای رفاه

نگاه به برنامه DevOops 2020 مسکو - همچنین چیزهای جالب زیادی در آنجا وجود دارد.

منبع: www.habr.com