أصبح موضوع DevOps شائعًا جدًا خلال السنوات القليلة الماضية. يحلم الكثيرون بالانضمام إليها ، لكن كما تظهر الممارسة ، غالبًا فقط بسبب مستوى الرواتب.
يشير البعض إلى DevOps في سيرتهم الذاتية ، على الرغم من أنهم لا يعرفون ويفهمون دائمًا جوهر المصطلح. يعتقد شخص ما أنه بعد دراسة Ansible و GitLab و Jenkins و Terraform وما شابه (يمكن متابعة القائمة حسب ذوقك) ، سيصبح على الفور "devops". هذا، بالطبع، ليس صحيحا.
على مدار السنوات القليلة الماضية ، شاركت بشكل أساسي في تنفيذ DevOps في العديد من الشركات. قبل ذلك ، عمل لأكثر من 20 عامًا في مناصب من مسؤول النظام إلى مدير تكنولوجيا المعلومات. حاليًا مهندس رئيسي DevOps في Playgendary.
من هو DevOps
نشأت فكرة كتابة مقال بعد سؤال آخر: "من هو DevOps؟". لا يوجد حتى الآن مصطلح محدد لما هو أو من هو. بعض الإجابات موجودة بالفعل في هذا . أولاً ، سأقوم بتسليط الضوء على الأطروحات الرئيسية منه ، ثم سأشارك ملاحظاتي وأفكاري.
DevOps ليست متخصصة في التوظيف ، وليست مجموعة من المرافق ، وليست قسم تطوير به مهندسين.
DevOps هي فلسفة ومنهجية.
بمعنى آخر ، إنها مجموعة من الممارسات التي تساعد المطورين على التفاعل بنشاط مع مسؤولي النظام. أي لربط ودمج عمليات العمل مع بعضها البعض.
مع ظهور DevOps ، ظل هيكل وأدوار المتخصصين كما هو (هناك مطورون ، وهناك مهندسون) ، لكن قواعد التفاعل قد تغيرت. الحدود بين الإدارات غير واضحة.
يمكن تلخيص أهداف DevOps في ثلاث نقاط:
- يجب تحديث البرنامج بانتظام.
- يجب عمل البرنامج بسرعة.
- يجب نشر البرنامج بسهولة وفي وقت قصير.
لا تملك DevOps أداة واحدة. لا يعني إعداد منتجات متعددة وتقديمها والتعرف عليها أن DevOps موجود في الشركة. هناك الكثير من الأدوات وكلها تشارك في مراحل مختلفة ، ولكنها تخدم هدفًا واحدًا مشتركًا.
وهذا مجرد جزء من أدوات DevOps
لأكثر من عامين أقوم بإجراء مقابلات مع أشخاص لمنصب مهندس DevOps ، وأدركت مدى أهمية فهم جوهر المصطلح بوضوح. لقد تراكمت لدي خبرة وملاحظات وأفكار محددة أريد مشاركتها.
من تجربة المقابلات أرى هذه الصورة: عادة ما يعاني المحترفون الذين يعتبرون موقع DevOps من سوء فهم مع زملائهم.
كان هناك مثال رئيسي. جاء شاب إلى المقابلة حاملاً مجموعة من الكلمات الطنانة في سيرته الذاتية. في أماكن العمل الثلاثة الأخيرة ، كانت لديه خبرة من 5-6 أشهر. ترك شركتين ناشئتين لأنهما "لم تنطلقان". ولكن بخصوص الشركة الثالثة ، قال إنه لا أحد يفهمه هناك: يكتب المطورون الكود الخاص بـ Windows ، ويقوم المخرج "بالتفاف" في Docker المعتاد وتضمينه في خط أنابيب CI / CD. قال الرجل الكثير من الأشياء السلبية عن مكان عمله الحالي وزملائه - أردت فقط أن أجيب: "لذلك لن تبيع فيلًا."
ثم سألته سؤالاً يعد من أول الأسئلة في قائمتي لكل مرشح.
ماذا تعني لك DevOps شخصيًا؟
- بشكل عام ، أو كيف أفهمه؟
كنت مهتمًا برأيه الشخصي. كان يعرف النظرية وأصل المصطلح ، لكنه اختلف معه بشدة. كان يعتقد أن DevOps كان موقفًا. هذا هو المكان الذي يكمن فيه جذر مشاكله. وكذلك خبراء آخرين بنفس الرأي.
بعد أن سمع أصحاب العمل الكثير عن "سحر DevOps" ، يريدون العثور على شخص سيأتي ويصنع هذا "السحر". ما لا يدركه الباحثون عن عمل "DevOps هي وظيفة" هو أنهم لن يكونوا قادرين على تلبية التوقعات من خلال هذا النهج. وبشكل عام ، كتبوا DevOps في سيرتهم الذاتية ، لأن هذا اتجاه ويدفعون الكثير مقابل ذلك.
منهجية وفلسفة DevOps
المنهجية نظرية وعملية. في حالتنا الثانية. كما ذكرت أعلاه ، فإن DevOps عبارة عن مجموعة من الممارسات والاستراتيجيات المستخدمة لتحقيق الأهداف المذكورة. وفي كل حالة ، اعتمادًا على العمليات التجارية للشركة ، يمكن أن تختلف بشكل كبير. هذا لا يجعلها أفضل أو أسوأ.
منهجية DevOps هي مجرد وسيلة لتحقيق أهدافك.
الآن حول ما هي فلسفة DevOps. وربما يكون هذا هو السؤال الأكثر صعوبة.
من الصعب جدًا صياغة إجابة قصيرة وواسعة ، لأنها لم يتم إضفاء الطابع الرسمي عليها بعد. ونظرًا لأن أتباع فلسفة DevOps أكثر انخراطًا في الممارسة ، فليس هناك وقت للتفلسف. ومع ذلك ، فهذه عملية مهمة للغاية. علاوة على ذلك ، تتعلق مباشرة بالأنشطة الهندسية. حتى أن هناك مجالًا متخصصًا للمعرفة - .
لم يكن هناك مثل هذا الموضوع في جامعتي ، كان علي أن أدرس كل شيء بمفردي باستخدام المواد التي يمكن أن أجدها في التسعينيات. الموضوع اختياري للتعليم الهندسي ، وبالتالي عدم إضفاء الطابع الرسمي على الإجابة. لكن هؤلاء الأشخاص المنغمسين بجدية في DevOps يبدأون في الشعور "بروح" معينة أو "شمولية غير واعية" لجميع عمليات الشركة.
بناءً على تجربتي الخاصة ، حاولت إضفاء الطابع الرسمي على بعض "افتراضات" هذه الفلسفة. اتضح ما يلي:
- إن DevOps ليس شيئًا مستقلاً يمكن فصله إلى مجال منفصل للمعرفة أو النشاط.
- يجب أن توجه منهجية DevOps جميع موظفي الشركة عند التخطيط لأنشطتهم.
- تؤثر DevOps على جميع العمليات داخل الشركة.
- توجد DevOps لتقليل الوقت الذي تقضيه في أي عمليات داخل الشركة لضمان تطوير خدماتها وتحقيق أقصى قدر من الراحة للعميل.
- DevOps ، بالمصطلحات الحديثة ، هو الموقف الاستباقي لكل موظف في الشركة ، ويهدف إلى تقليل تكاليف الوقت وتحسين جودة منتجات تكنولوجيا المعلومات من حولنا.
أعتقد أن "افتراضاتي" موضوع منفصل للمناقشة. ولكن الآن هناك شيء يمكن البناء عليه.
ماذا تفعل DevOps؟
الكلمة الأساسية هنا هي التواصل. هناك الكثير من الاتصالات ، يجب أن يكون منشئها هو نفس مهندس DevOps. لماذا هذا؟ لأنها فلسفة ومنهجية ، وعندها فقط معرفة هندسية.
لا يمكنني التحدث بيقين 100٪ عن سوق العمل الغربي. لكني أعرف الكثير عن سوق DevOps في روسيا. بالإضافة إلى مئات المقابلات ، فقد شاركت خلال العام ونصف العام الماضيين في مئات من ما قبل البيع التقني على خدمة تنفيذ DevOps للشركات والبنوك الروسية الكبيرة.
في روسيا ، لا تزال DevOps صغيرة جدًا ، ولكنها بالفعل موضوع شائع. على حد علمي ، في موسكو وحدها ، بلغ النقص في هؤلاء المتخصصين في عام 2019 أكثر من 1000 شخص. وكلمة Kubernetes لأصحاب العمل تشبه قطعة قماش حمراء للثور. إن أتباع هذه الأداة على استعداد لاستخدامها حتى عندما لا تكون هناك حاجة إليها وتكون غير مربحة اقتصاديًا. لا يفهم صاحب العمل دائمًا ما هو أكثر ملاءمة للاستخدام ، ومع النشر المناسب ، فإن صيانة مجموعة Kubernetes تكلف 2-3 مرات أكثر من نشر تطبيق باستخدام مخطط مجموعة تقليدي. استخدمه حيث تحتاجه حقًا.
يعد تنفيذ DevOps مكلفًا من حيث المال. وهي مبررة فقط عندما تجلب منافع اقتصادية في مناطق أخرى ، وليس من تلقاء نفسها.
يعتبر مهندسو DevOps في الواقع روادًا - فهم أول من طبق هذه المنهجية في الشركة وبناء العمليات. لكي يكون هذا ناجحًا ، يجب أن يتفاعل المتخصص باستمرار مع الموظفين والزملاء على جميع المستويات. كما أقول عادةً ، يجب أن يشارك جميع موظفي الشركة في عملية تنفيذ DevOps: بدءًا من المسؤول وحتى المدير التنفيذي. وهذا شرط أساسي. إذا كان أصغر عضو في الفريق لا يعرف ويفهم ماهية DevOps ولماذا يتم تنفيذ إجراءات تنظيمية معينة ، فلن ينجح التنفيذ الناجح.
أيضًا ، يحتاج مهندس DevOps إلى استخدام مورد إداري من وقت لآخر. على سبيل المثال ، للتغلب على "المقاومة البيئية" - عندما لا يكون الفريق مستعدًا لقبول أدوات ومنهجيات DevOps.
يجب على المطور كتابة التعليمات البرمجية والاختبارات فقط. للقيام بذلك ، لا يحتاج إلى جهاز كمبيوتر محمول فائق القوة حيث سينشر ويحافظ على البنية التحتية للمشروع بالكامل محليًا. على سبيل المثال ، يحتفظ الواجهة الأمامية بجميع عناصر التطبيق على الكمبيوتر المحمول الخاص به ، بما في ذلك قاعدة البيانات ومحاكي S3 (minio) وما إلى ذلك. أي أنه يقضي الكثير من الوقت في صيانة هذه البنية التحتية المحلية ويكافح بمفرده مع جميع مشاكل مثل هذا الحل. بدلا من تطوير كود للجبهة. يمكن لمثل هؤلاء الأشخاص مقاومة أي تغييرات بشدة.
لكن هناك فرق ، على العكس من ذلك ، سعيدة بإدخال أدوات وأساليب جديدة ، وتشارك بنشاط في هذه العملية. على الرغم من أنه حتى في هذه الحالة ، لم يقم أحد بإلغاء الاتصال بين مهندس DevOps والفريق.
عندما لا تكون هناك حاجة إلى DevOps
هناك حالات لا يلزم فيها DevOps. هذه حقيقة - يجب فهمها وقبولها.
بادئ ذي بدء ، ينطبق هذا على أي شركة (خاصة الشركات الصغيرة) عندما لا تعتمد أرباحها بشكل مباشر على وجود أو عدم وجود منتجات تكنولوجيا المعلومات التي تقدم خدمات المعلومات للعملاء. وهنا لا نتحدث عن موقع الشركة ، سواء كان "بطاقة عمل" ثابتة أو مع كتل إخبارية ديناميكية ، إلخ.
مطلوب DevOps عندما يكون توافر خدمات المعلومات هذه للتفاعل مع العميل ، وتعتمد جودتها واستهدافها على إرضاء العميل ورغبته في العودة إليك مرة أخرى.
بنك معروف هو مثال ساطع. لا يوجد لدى الشركة مكاتب العملاء المعتادة ، ويتم تنفيذ تدفق المستندات عبر البريد أو البريد ، ويعمل العديد من الموظفين من المنزل. لم تعد الشركة مجرد بنك ، وفي رأيي تحولت إلى شركة لتكنولوجيا المعلومات مع تقنيات DevOps المتطورة.
يمكن العثور على العديد من الأمثلة والمحاضرات الأخرى في سجلات اللقاءات والمؤتمرات المواضيعية. قمت بزيارة البعض منهم شخصيًا - هذه تجربة مفيدة جدًا لأولئك الذين يرغبون في التطور في هذا الاتجاه. فيما يلي روابط لقنوات YouTube التي تحتوي على محاضرات ومواد جيدة على DevOps:
انظر الآن إلى عملك وفكر في هذا: إلى أي مدى تعتمد شركتك وأرباحها على منتجات تكنولوجيا المعلومات لتقديم تجربة العملاء؟
إذا كانت شركتك تبيع الأسماك في متجر صغير وكان منتج تكنولوجيا المعلومات الوحيد هو تكوينات 1C: Enterprise (Accounting and UNF) ، فليس من المنطقي التحدث عن DevOps.
إذا كنت تعمل في مؤسسة تجارية وتصنيعية كبيرة (على سبيل المثال ، تنتج بنادق صيد) ، فعليك التفكير في الأمر. يمكنك أخذ زمام المبادرة وإحضار رؤية تنفيذ DevOps إلى إدارتك. حسنًا ، في نفس الوقت ، لقيادة هذه العملية. الموقف الاستباقي هو أحد الافتراضات المهمة لفلسفة DevOps.
لا يُعد حجم وحجم المبيعات المالية السنوية المعيار الرئيسي لتحديد ما إذا كانت شركتك بحاجة إلى DevOps.
تخيل مؤسسة صناعية كبيرة لا تتفاعل مباشرة مع العملاء. على سبيل المثال ، بعض شركات صناعة السيارات والسيارات. لست متأكدًا الآن ، ولكن من تجربتي السابقة ، لسنوات عديدة ، كان كل التفاعل مع العملاء يتم عن طريق البريد الإلكتروني والهاتف.
عملاؤهم عبارة عن قائمة محدودة من تجار السيارات. ويتم إرفاق متخصص من الشركة المصنعة لكل منهما. يحدث تدفق المستندات الداخلية بالكامل من خلال SAP ERP. الموظفون الداخليون ، في الواقع ، هم عملاء نظام المعلومات. لكن إدارة هذا IS تتم بالوسائل الكلاسيكية لإدارة أنظمة المجموعات. مما يستبعد إمكانية استخدام ممارسات DevOps.
ومن هنا الاستنتاج: بالنسبة لمثل هذه المؤسسات ، لا يعد تنفيذ DevOps أمرًا بالغ الأهمية ، إذا تذكرنا أهداف المنهجية من بداية المقالة. لكني لا أستبعد أن يتم استخدام بعض أدوات DevOps من قبلهم اليوم.
من ناحية أخرى ، هناك العديد من الشركات الصغيرة التي تطور البرامج باستخدام منهجية وفلسفة وممارسات وأدوات DevOps. ويعتقدون أن تكلفة تنفيذ DevOps هي تكلفة تسمح لهم بالمنافسة بفعالية في سوق البرمجيات. يمكن رؤية أمثلة على هذه الشركات .
المعيار الرئيسي لفهم ما إذا كانت هناك حاجة إلى DevOps: ما هي قيمة منتجات تكنولوجيا المعلومات الخاصة بك للشركة والعملاء.
إذا كان المنتج الرئيسي المربح للشركة هو البرامج ، فأنت بحاجة إلى DevOps. وليس من المهم جدًا أن تكسب أموالًا حقيقية بمساعدة سلع أخرى. يمكن أن يشمل ذلك أيضًا المتاجر عبر الإنترنت أو تطبيقات الأجهزة المحمولة التي تحتوي على ألعاب.
أي ألعاب موجودة بسبب تمويل: مباشر أو غير مباشر من اللاعبين. في Playgendary ، نقوم بتطوير ألعاب محمولة مجانية مع أكثر من 200 شخص يشاركون بشكل مباشر في الإنشاء. كيف نستخدم DevOps؟
نعم ، بالضبط كما هو موضح أعلاه. أتواصل باستمرار مع المطورين والمختبرين ، وأجري تدريبًا داخليًا على منهجية وأدوات DevOps للموظفين.
نحن الآن نستخدم Jenkins بنشاط كأداة لخطوط أنابيب CI / CD لأداء جميع خطوط أنابيب التجميع باستخدام Unity والنشر اللاحق في App Store و Play Market. المزيد من مجموعة الأدوات الكلاسيكية:
- Asana - لإدارة المشاريع. قم بإعداد التكامل مع Jenkins.
- Google Meet - لاجتماعات الفيديو.
- Slack - للاتصالات والإشعارات المختلفة ، بما في ذلك الإخطارات من Jenkins.
- ملتقى Atlassian - للتوثيق والعمل الجماعي.
في المستقبل القريب ، نخطط لتنفيذ تحليل الكود الثابت باستخدام SonarQube وإجراء اختبار آلي لواجهة المستخدم باستخدام السيلينيوم في مرحلة التكامل المستمر.
بدلا من خاتمة
أريد أن أنهي بالفكرة التالية: لكي تصبح مهندسًا مؤهلًا بدرجة عالية في DevOps ، من الضروري أن تتعلم كيفية التواصل مع الناس بشكل مباشر.
مهندس DevOps هو لاعب فريق. ولا شيء غير ذلك. يجب أن تأتي المبادرة في التواصل مع الزملاء منه ، وليس تحت تأثير أي ظرف من الظروف. يحتاج متخصص DevOps إلى رؤية واقتراح أفضل حل للفريق.
ونعم ، سيتطلب تنفيذ أي حل الكثير من النقاش ، وقد يتغير في النهاية. تطوير الذات وتقديم وتنفيذ أفكاره - مثل هذا الشخص له قيمة متزايدة للفريق وصاحب العمل. والذي ينعكس في النهاية في مقدار أجره الشهري أو في شكل مكافآت إضافية.
المصدر: www.habr.com