دواپس چیست؟ بخش اول

مقدمه DevOps چیست؟

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

دواپس چیست؟

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

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

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

ثبت نام در دوره DevOps
https://www.ahmadzadeh.academy/product/devops/

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

تاریخچه Devops

دواپس توسعه دهنده به عنوان اپراتور

در ابتدا، توسعه دهنده اپراتور بود. برنامه نویسان اولیه در واقع به عنوان کامپیوترهای انسانی شناخته می شدند. ژان بارتیک، یکی از برنامه نویسان اصلی انتگرالگر و کامپیوتر عددی الکترونیکی (ENIAC) نحوه برنامه ریزی دستگاه را با بررسی نمودارهای سخت افزاری و منطقی دستگاه یاد گرفت.

برنامه نویسی دستگاه و 18000 لوله خلاء آن به معنای تنظیم شماره گیری و تغییر اتصالات کابل در 40 پانل کنترل بود. در آن زمان، تمرکز بر مهندسی سخت‌افزار بود و نه بر روی نرم‌افزار که Bartik، Kathleen Antonelli، Frances Holberton، مارلین ملتزر، فرانسیس اسپنس و روث تیتلبام در ENIAC ساخته شده اند.

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

ظهور مهندسی نرم افزار

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

با یک ضرب الاجل و بدون کارمندی با مهارت های لازم، اداره ملی هوانوردی و فضایی (ناسا) باید فردی را پیدا می کرد تا نرم افزار پرواز داخلی مورد نیاز برای انجام این کار را بنویسد.

ناسا مارگارت همیلتون، ریاضیدان مؤسسه فناوری ماساچوست (MIT) را برای رهبری نوشتن این نرم افزار حیاتی استخدام کرد. در پیگیری نوشتن این نرم افزار پیچیده، همیلتون به دلیل ابداع اصطلاح "مهندسی نرم افزار" اعتبار دارد. او همچنین مفهوم نمایشگرهای اولویت را ایجاد کرد، نرم افزاری که به فضانوردان هشدار می دهد تا تنظیمات را در زمان واقعی به روز کنند.

او مجموعه ای از جمع آوری الزامات را ایجاد کرد که شامل:

• اشکال زدایی تمام اجزای جداگانه
• تست تک تک اجزا قبل از مونتاژ
• تست ادغام

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

در سال 1967، بحث‌هایی توسط کمیته علمی ناتو متشکل از دانشمندان سراسر کشورها و صنایع برای ارزیابی مهندسی نرم‌افزار برگزار شد.

یک گروه مطالعاتی در زمینه علوم کامپیوتر در پاییز 1967 تشکیل شد. هدف این بود که توجه را بر مشکلات نرم افزار متمرکز کند. آن ها کنفرانسی را با دعوت از 50 کارشناس از تمام حوزه های صنعت برنامه ریزی کردند. 3 کارگروه این کنفرانس طراحی نرم افزار، تولید نرم افزار و سرویس نرم افزار بود. هدف تلاش برای تعریف، توصیف و راه اندازی حل مشکلات مهندسی نرم افزار بود.

در کنفرانس مهندسی نرم افزار ناتو در سال 1968، مشکلات کلیدی در مهندسی نرم افزار شناسایی شد، از جمله:

• تعریف و سنجش موفقیت
• ساختن سیستم های پیچیده که نیاز به سرمایه گذاری زیاد و امکان سنجی ناشناخته دارد
• تولید سیستم ها بر اساس زمان بندی و مشخصات
• فشارهای اقتصادی بر تولیدکنندگان برای ساخت محصولات خاص

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

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

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

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

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

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

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

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

عصر سیستم عامل (The Age of the Operating System)

در سال 1979، Usenet توسط دانشجویان دانشگاه - تام تروسکات، جیم الیس، و استیو بلووین راه اندازی شد. این به عنوان یک اسکریپت پوسته ساده شروع شد که به طور خودکار رایانه های مختلف را فراخوانی می کرد، تغییرات را در فایل های آن رایانه ها جستجو می کرد و تغییرات را کپی می کرد.

یک کامپیوتر به کامپیوتر دیگر با استفاده از UUCP (کپی یونیکس به یونیکس، مجموعه ای از برنامه ها که امکان انتقال فایل و اجرای دستور از راه دور بین رایانه ها را فراهم می کند).

برای بهبود عملکرد، سپس در سی بازنویسی شد. الیس در یک گروه آکادمیک کاربران یونیکس که به نام یونیکس شناخته می شود، در مورد "دعوت به یک شبکه دسترسی عمومی یونیکس" سخنرانی کرد.

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

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

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

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

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

سایر گروه‌های تخصصی‌تر نیز حذف شدند و NOC (مرکز عملیات شبکه)، QA، امنیت، پایگاه‌های اطلاعاتی و ذخیره‌سازی همگی به حوزه‌های نگرانی جداگانه تبدیل شدند.

زیرساخت چابک در DevOps

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

در عملیات «عملیات و زیرساخت چابک: چقدر زیرشاخه هستید؟». پاتریک با تیم های توسعه و عملیات روی پروژه ای برای آزمایش مهاجرت مرکز داده کار کرد. یک روز او روی توسعه چابک با توسعه دهندگان کار می کرد

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

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

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

پل هاموند در سال 2007 به تیم توسعه فلیکر پیوست و در سال 2008 به عنوان مدیر مهندسی فلیکر با همکاری Allspaw سرپرست سازمان توسعه شد.

هاموند و آلسپاو به طور مشترک در Velocity Santa Clara 2009 "10+ Deploys per Day" را ارائه کردند و تغییرات انقلابی را برجسته کردند که به تیم اجازه داد تا به سرعت حرکت کند. آنها این کار را با هدف تخریب سیلوها یا راه اندازی یک جنبش بزرگ حرفه ای و فرهنگی انجام ندادند.

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

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

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

آدرس لینکدین من:

اینجا کلیک کن

آدرس سایت آکادمی احمدزاده:

اینجا کلیک کن

مدیریت چابک:

https://www.ahmadzadeh.academy/category/article/project-management-article/

https://www.ahmadzadeh.academy/acp/

حتما مقاله های زیر رو مطالعه کنید:

هزینه کیفیت پروژه و نکات کلیدی آن در آزمون جدید PMP

هزینه های آزمون PMP چقدر است؟

دوره مدیریت چابک

مدیریت چابک

6 دلیل برای اینکه کسب و کارها باید چابک شوند

تحلیل کسب و کار چیست؟