چگونه Vanguard و Morgan Stanley بین توسعه‌دهندگان و عملیات‌ها تعادل برقرار می‌کنند

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

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

Vanguard در حال گذراندن چیزی است که آن را تغییر تکراری می نامد. از مدیریت ۲۰۰۰ سرور خود در سال ۲۰۱۵ تا اجرای بیشتر در وب آمازون خدمات (AWS). در نتیجه، ۷۰۰۰ توسعه‌دهنده آن از به‌روزرسانی برنامه‌های کاربردی یکپارچه در یک چرخه فصلی به مجموعه‌ای از سرویس‌های میکرو که توسط تیم‌های مجزا ساخته و اجرا می‌شوند، حرکت کرده‌اند.

این تیم‌ها اکنون توسط تیم پلتفرم متمرکز پشتیبانی می‌شوند که خطوط لوله و زیرساخت استاندارد CI/CD را برای ورود کدشان با مهندسی قابلیت اطمینان سایت (SRE) فراهم می‌کند. نظارت هم به صورت مرکزی و هم در آن تیم ها تعبیه شده است.

مورگان استنلی تحول چابک و ابری خود را در سال ۲۰۱۸ آغاز کرد و از نزدیک‌تر همراستا با Microsoft Azure.

این ابتکار با یک تلاش آموزشی سه ساله برای ایجاد شیوه‌های مدرن devops و SRE در بین ۱۵۰۰۰ فن‌آور بانک آغاز شد. این برنامه به چیزی بستگی داشت که گاس پل، مدیر اجرایی زیرساخت برنامه در مورگان استنلی، سه حوزه کلیدی را شناسایی کرد: «تسریع توسعه و تحویل نرم‌افزار. افزایش قابلیت پیش بینی، فراوانی و کیفیت تغییرات؛ و انقلابی در نحوه عملکرد ما در فناوری ایجاد کند،» او در طی ارائه ای در اجلاس Devops Enterprise Summit گفت.

ترور برازنان، رئیس توسعه و معماری فناوری سازمانی در مورگان استنلی، امروز، مورگان استنلی «تیم‌های چابکی با مالک محصول، مهندسانی با تخصص توسعه‌دهنده و عملیاتی دارد، و آنها می‌توانند زیرساخت‌های داخلی یا ابری را هدف قرار دهند». به InfoWorld گفت. “فلسفه من این است که همه تخصص هایی دارند. همه ما در فناوری یک ابرقدرت داریم.”

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

انعطاف پذیری و مدیریت ریسک

کریستینا یاکومین یک مهندس قابلیت اطمینان سایت در Vanguard است، جایی که او بخشی از تیمی است که از تیم‌های توسعه‌دهنده همسو با تجارت پشتیبانی می‌کند. تیم او با اجرای آنچه او «سکوهای خدمات مشترک» می‌نامد، مانند خطوط لوله CI/CD و سکوهای زیرساخت ابری استاندارد شده، کنترل‌های استقرار خاصی را تنظیم و اجرا می‌کند.

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

در نظر گرفتن برگی از کتاب بازی “مسیر طلایی” غول استریم Spotify، Yakomin به وضوح تحت تأثیر مفهوم بومی ابری ارائه مسیرهای طلایی برای توسعه دهندگان قرار گرفته است. او گفت: «ما دریافتیم که به دلیل پیچیده بودن کنترل‌های لازم برای ساخت برنامه‌های کاربردی در این صنعت، تلاش می‌کنیم تا مسیر استاندارد را با طلا هموار کنیم و در عین حال مطمئن شویم که انحراف باز است.

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

با وجود ساختار مشابه، مورگان استنلی رویکرد متفاوتی را برای مدیریت ریسک هنگام استقرار در تولید اتخاذ می کند. قبلاً، این نیاز به یک توسعه‌دهنده داشت که بین سه نمونه جداگانه Jira جابجا شود، یک بلیط تغییر را ثبت کند و ۸۱ مرحله را دنبال کند تا حتی یک خط کد تأیید شود. اکنون، بانک شروع به اتخاذ زیرساخت‌های مدرن به‌عنوان کد و شیوه‌های CI/CD کرده است تا این فرآیند را در میان تیم‌های توسعه‌دهنده متنوع خود، با یک تیم مرکزی که مسئول تشویق و تشویق سایر تیم‌ها به پیروی از آن هستند، ساده‌سازی کند. .

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

پتوی ایمنی SRE

قرار دادن یک پتوی ایمنی SRE در سطح عملیات مرکزی و در درون تیم‌های توسعه‌دهنده منفرد به ایجاد اطمینان در Vanguard و Morgan Stanley کمک کرده است که تعادل مناسبی بین سرعت توسعه‌دهنده و ثبات عملیاتی ایجاد می‌کنند.

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

یاکومین گفت: «این یک مشکل ظریف برای حل است. “معرفی SRE باعث می‌شود مردم احساس کنند که ما دوباره به آن نقش می‌پردازیم.”

برازنان گفت:

به طور مشابه در مورگان استنلی، ایجاد اصول SRE “گاهی اوقات به عنوان تغییر نام تجاری تیم عملیاتی اشتباه درک می شود.”

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

رابی دایتزمن، مدیر ارشد پلتفرم فناوری واسطه در Vanguard، گفت که آنها توانستند با “ایجاد یک فریاد جمعی برای متمرکز شدن در اطراف پلتفرم های خاص” بر این مشکل غلبه کنند. او گفت که تمرکز “با متعادل کردن بار شناختی و اجرای مدل مسئولیت مشترک، برای مهندسان مفید است.”

به‌طور مشابه، در مورگان استنلی، برازنان «SRE را به‌عنوان عبور از توسعه‌دهندگان و عملیات‌ها و کل چرخه عمر توسعه» می‌بیند. به عنوان مثال، عمل اساسی SRE برای حذف زحمت معمولاً توسط متخصصان عملیات بیشتر احساس می شود، اما توسعه دهندگان برای خودکارسازی این وظایف خسته کننده مناسب هستند. برازنان گفت: یا قابلیت اطمینان، که یکی از دغدغه‌های اصلی SRE است، نیز بر عهده توسعه‌دهندگانی است که وظیفه دارند برنامه‌های خود را طراحی کنند تا در هسته خود انعطاف‌پذیر باشند.

ساختن سیستم های قابل مشاهده و انعطاف پذیر

تیم مرکزی SRE در Vanguard همچنین مسئول اطمینان از انعطاف پذیری و قابل مشاهده بودن سیستم های مختلف آن است.

یاکومین و دایتزمن هر دو قبلاً در تیم مهندسی آشوب در Vanguard کار کرده بودند. روزهای بازی آشوب و مانورهای آتش از قبل کلیدی برای اعتبار بخشیدن به انعطاف پذیری سیستم های جدید در شرکت بودند.

Vanguard همچنین از قابلیت مشاهده فقط هشدار سیستم‌های اصلی خود به استفاده از Amazon CloudWatch، نظارت بر بستر ابری Honeycomb، و استاندارد منبع باز OpenTelemetry برای جمع‌آوری معیارها، گزارش‌ها و ردیابی‌ها تغییر مکان داد. p>

دایتزمن گفت: “مشاهده پذیری در SRE برای مهندسان یک چیز با کیفیت زندگی بوده است تا بفهمند آیا ما در شرایط خوبی هستیم یا بر مشتریان تاثیر منفی می گذارد.” “این همچنین به ادعای بی گناهی در مدل مسئولیت مشترک کمک می کند.”

علاوه بر این معیارهای مشاهده پذیری مشترک، Vanguard مجموعه ای از داشبوردهای داخلی را ایجاد کرده است که می تواند توسط هر تیم توسعه دهنده مطابق با نیازهای خود بهینه شود.

با این حال، این موضوع باعث نشده که تیم‌ها برای آخرین و بهترین پلتفرم مشاهده‌پذیری در بالای این زیرساخت فریاد بزنند. یاکومین گفت: “هر تیمی چیزهای متفاوتی می خواهد و اگر همه اینها را داشتیم بسیار گران بود.”

به دنبال تعادل مناسب

علی‌رغم این همه پیشرفت، یاکومین اعتراف می‌کند که تیم او در Vanguard همچنان در تلاش است تا تعادل مناسب بین کارایی و انعطاف‌پذیری را برای توسعه‌دهندگان خود ایجاد کند.

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

برای برازنان در مورگان استنلی، “شما هرگز واقعاً تمام نشدید.” او متعهد شد که به “تمرکز بر حفظ آن شتاب جامعه، برای کمک به تبدیل شدن آن به بخشی دائمی از فرهنگ” ادامه دهد.