ليس هناك وقت أفضل للتعلم في الحياة من اليوم.
إنه عام 2019، وقد أصبحت DevOps أكثر أهمية من أي وقت مضى. يقولون أن أيام مسؤولي النظام قد انتهت، تماما مثل عصر الحاسوب المركزي. ولكن هل هذا حقا؟
كما يحدث غالبًا في مجال تكنولوجيا المعلومات، فقد تغير الوضع. لقد ظهرت منهجية DevOps، لكنها لا يمكن أن توجد بدون شخص يتمتع بمهارات مسؤول النظام، أي بدون Ops.
قبل أن يتخذ نهج DevOps شكله الحديث، صنفت نفسي كمسؤول عن العمليات. وأنا أعلم جيدًا ما يختبره مسؤول النظام عندما يدرك مقدار ما لا يستطيع فعله بعد ومدى قلة الوقت المتاح له لتعلمه.
ولكن هل هو حقا مخيف؟ أود أن أقول إن نقص المعرفة لا ينبغي أن يُنظر إليه على أنه مشكلة كبيرة. إنه تحدٍ احترافي أكثر.
تعتمد المنتجات على نطاق الويب على Linux أو أي برامج أخرى مفتوحة المصدر، وهناك عدد أقل فأقل من الأشخاص في السوق القادرين على صيانتها. لقد تجاوز الطلب بالفعل عدد المتخصصين في هذا المجال. لن يتمكن مسؤول النظام بعد الآن من مواصلة العمل ببساطة دون تحسين مستوى مهاراته. يجب أن يتمتع بمهارات الأتمتة لإدارة خوادم/عقد متعددة وأن يكون لديه فهم جيد لكيفية عملها لحل المشكلات التي تنشأ.
قبل أن تصبح عضوًا في فريق DevOps، يتعين عليك خوض رحلة طويلة ولكنها مثيرة للاهتمام، وتعلم تقنيات جديدة وأدوات متنوعة ضرورية لصيانة النظام وفقًا لمعايير DevOps.
إذًا، كيف يمكن لمسؤول النظام الانتقال من النهج المعتاد للعمل إلى المفهوم الجديد لـ DevOps؟ كل شيء كالمعتاد: عليك أولاً تغيير تفكيرك. ليس من السهل التخلي عن النهج الذي كنت تتبعه طوال العشر أو العشرين عامًا الماضية والبدء في فعل الأشياء بشكل مختلف، لكنه ضروري.
أولاً، من المهم أن نفهم أن DevOps ليست منصبًا محددًا في الشركة، ولكنها مجموعة من الممارسات المحددة. تتضمن هذه الممارسات توزيع أنظمة معزولة، وتقليل الضرر الناجم عن الأخطاء والأخطاء، وتحديثات البرامج المتكررة وفي الوقت المناسب، والتفاعل الراسخ بين المطورين (Dev) والمسؤولين (Ops)، بالإضافة إلى الاختبار المستمر ليس فقط للتعليمات البرمجية، ولكن أيضًا أيضا الهيكل بأكمله داخل العملية .
إلى جانب تغيير طريقة التفكير، تحتاج إلى تعلم كيفية الحفاظ على البنية التحتية وضمان تشغيلها المستقر وموثوقيتها وتوافرها للتكامل المستمر وتقديم التطبيقات والخدمات والبرامج.
ما قد تفتقده كمحترف في العمليات هو مهارات البرمجة. الآن، تعتبر كتابة البرامج النصية (البرامج النصية)، التي يستخدمها مسؤولو النظام لتثبيت التصحيحات تلقائيًا على الخادم، وإدارة الملفات والحسابات، واستكشاف المشكلات وإصلاحها وتجميع الوثائق، أمرًا قديمًا بالفعل. لا تزال البرمجة النصية قابلة للتطبيق في حالات بسيطة نسبيًا، ولكن DevOps تدور حول حل المشكلات واسعة النطاق، سواء كان ذلك التنفيذ أو الاختبار أو البناء أو النشر.
وبالتالي، إذا كنت ترغب في تعلم الأتمتة، فأنت بحاجة إلى إتقان القليل من البرمجة على الأقل، حتى لو لم تكن مطورًا، لأنه في هذه المرحلة من تطورك في DevOps يتطلب هذه المهارة.
ما يجب القيام به؟ لكي تظل مطلوبًا كمتخصص، تحتاج إلى اكتساب المهارات ذات الصلة - إتقان لغة برمجة واحدة على الأقل، على سبيل المثال Python. قد يبدو هذا صعبا بالنسبة لشخص متخصص في الإدارة، لأنه معتاد على الاعتقاد بأن البرنامج هو مطورو البرامج فقط. ليس من الضروري أن تصبح خبيرا، ولكن معرفة إحدى لغات البرمجة (يمكن أن تكون Python أو Bash أو حتى )، سيكون بالتأكيد ميزة.
يستغرق تعلم البرمجة بعض الوقت. سيساعدك التحلي باليقظة والصبر على البقاء على اطلاع بالأمور عند التواصل مع أعضاء فريق DevOps والعملاء. نصف ساعة يوميا، ساعة أو أكثر، تعلم لغة برمجة يجب أن يكون هدفك الأساسي.
يقوم مسؤولو النظام ومتخصصو DevOps بحل مشكلات مماثلة، ولكن هناك اختلافات كبيرة. من المعتقد أن مسؤول النظام لا يمكنه فعل كل ما يستطيعه مهندس DevOps. يقولون أن مسؤول النظام يركز بشكل أكبر على تكوين وصيانة وضمان أداء أنظمة الخادم، لكن مهندس DevOps يسحب كل هذه العربة وعربة أخرى صغيرة.
ولكن ما مدى صحة هذا البيان؟
مسؤول النظام: محارب واحد في الميدان
على الرغم من الاختلافات والتشابهات المذكورة في هذه المقالة، إلا أنني ما زلت أعتقد أنه لا يوجد فرق كبير بين إدارة الأنظمة وDevOps. لقد أدى مسؤولو النظام دائمًا نفس الوظائف التي يؤديها متخصصو DevOps، لكن لم يطلق عليها أحد اسم DevOps من قبل. أعتقد أنه لا فائدة من البحث على وجه التحديد عن الاختلافات، خاصة إذا لم تكن مرتبطة بأي مهمة. لا تنس أنه، على عكس مسؤول النظام، فإن DevOps ليس منصبًا، ولكنه مفهوم.
تجدر الإشارة إلى شيء آخر مهم، والذي بدونه لن تكتمل المحادثة حول كل من الإدارة وDevOps. تفترض إدارة النظام بالمعنى المعتاد أن يكون لدى المتخصص مجموعة محددة من المهارات ويركز على خدمة أنواع مختلفة من البنى التحتية. ليس بمعنى أن هذا موظف عالمي، ولكن بمعنى أن هناك عددًا من المهام التي يؤديها جميع المسؤولين.
على سبيل المثال، يتعين عليهم من وقت لآخر أن يتصرفوا كنوع من العامل الفني الماهر، أي أن يفعلوا كل شيء حرفيًا. وإذا كان هناك مسؤول واحد فقط للمؤسسة بأكملها، فسيقوم عموما بإجراء جميع الأعمال الفنية. يمكن أن يكون هذا أي شيء بدءًا من صيانة الطابعات وآلات التصوير وحتى أداء المهام المتعلقة بالشبكة مثل إعداد أجهزة التوجيه والمحولات وإدارتها أو تكوين جدار الحماية.
سيكون أيضًا مسؤولاً عن ترقيات الأجهزة، وفحص السجل وتحليله، وعمليات التدقيق الأمني، وتصحيح الخادم، واستكشاف الأخطاء وإصلاحها، وتحليل السبب الجذري، والأتمتة — عادةً من خلال البرامج النصية PowerShell أو Python أو Bash. أحد الأمثلة على الاستخدام هي إدارة حسابات المستخدمين والمجموعة. يعد إنشاء حسابات المستخدمين وتعيين الأذونات مهمة شاقة للغاية حيث يظهر المستخدمون ويختفون كل يوم تقريبًا. تعمل الأتمتة من خلال البرامج النصية على توفير الوقت لمهام البنية التحتية الأكثر أهمية، مثل ترقية المحولات والخوادم وغيرها من المشاريع التي تؤثر على ربحية الشركة التي يعمل فيها المسؤول (على الرغم من أنه من المقبول عمومًا أن قسم تكنولوجيا المعلومات لا يدر الدخل بشكل مباشر).
مهمة مسؤول النظام هي عدم إضاعة الوقت وتوفير أموال الشركة بأي طريقة ممكنة. في بعض الأحيان يعمل مسؤولو النظام كأعضاء في فريق كبير، ويوحدون، على سبيل المثال، مسؤولي Linux وWindows وقواعد البيانات والتخزين وما إلى ذلك. تختلف جداول العمل أيضًا. على سبيل المثال، يؤدي التحول في منطقة زمنية واحدة في نهاية اليوم إلى نقل الحالات إلى التحول التالي في منطقة زمنية أخرى بحيث لا تتوقف العمليات (اتبع الشمس)؛ أو أن يكون للموظفين يوم عمل عادي من الساعة 9 صباحًا حتى 5 مساءً؛ أو أنه يعمل في مركز بيانات يعمل على مدار الساعة طوال أيام الأسبوع.
بمرور الوقت، تعلم مسؤولو النظام التفكير بشكل استراتيجي والجمع بين الأمور المهمة والمهام الروتينية. عادة ما تكون الفرق والأقسام التي يعملون بها تعاني من نقص الموارد، ولكن في الوقت نفسه يحاول الجميع إكمال المهام اليومية على أكمل وجه.
DevOps: التطوير والصيانة كواحد
هو نوع من الفلسفة لعمليات التطوير والصيانة. لقد أصبح هذا النهج في عالم تكنولوجيا المعلومات مبتكرًا حقًا.
يوجد تحت مظلة DevOps فريق تطوير البرمجيات من جهة وفريق الصيانة من جهة أخرى. وغالبًا ما ينضم إليهم متخصصون في إدارة المنتجات، والمختبرون، ومصممو واجهات المستخدم. يعمل هؤلاء الخبراء معًا على تبسيط العمليات لطرح التطبيقات الجديدة وتحديثات التعليمات البرمجية بسرعة لدعم وتحسين كفاءة الشركة بأكملها.
يعتمد DevOps على التحكم في تطوير البرامج وتشغيلها طوال دورة حياتها بأكملها. يجب على موظفي الصيانة دعم المطورين، ويتم تكليف المطورين بفهم أكثر من مجرد واجهات برمجة التطبيقات المستخدمة في الأنظمة. إنهم بحاجة إلى فهم ما هو موجود تحت الغطاء (أي كيفية عمل الأجهزة وأنظمة التشغيل) حتى يتمكنوا من التعامل مع الأخطاء وحل المشكلات والتفاعل مع فنيي الخدمة بشكل أفضل.
يمكن لمسؤولي النظام الانتقال إلى فريق DevOps إذا كانوا يريدون تعلم أحدث التقنيات وكانوا منفتحين على الأفكار والحلول المبتكرة. كما قلت من قبل، ليس من الضروري أن يصبحوا مبرمجين كاملين، ولكن إتقان لغة برمجة مثل Ruby أو Python أو Go سيساعدهم على أن يصبحوا أعضاء مفيدين جدًا في الفريق. على الرغم من أن مسؤولي النظام يقومون عادةً بكل العمل بأنفسهم وغالبًا ما يُنظر إليهم على أنهم منعزلون، إلا أنهم في DevOps لديهم تجربة معاكسة تمامًا، حيث يتفاعل كل فرد في العملية مع بعضهم البعض.
أصبح موضوع الأتمتة ذا أهمية متزايدة. يهتم كل من مسؤولي النظام ومتخصصي DevOps بالتوسع بسرعة، وتقليل الأخطاء، والعثور بسرعة على الأخطاء الموجودة وإصلاحها. وبالتالي، فإن الأتمتة هي مفهوم يلتقي فيه مجالان. يتحمل مسؤولو النظام مسؤولية الخدمات السحابية مثل AWS وAzure وGoogle Cloud Platform. يجب أن يفهموا مبادئ التكامل المستمر والتسليم وكيفية استخدام أدوات مثل .
بالإضافة إلى ذلك، يجب على مسؤولي النظام استخدام أدوات التكوين والإدارة مثل وهو ضروري للنشر المتوازي لعشرة أو عشرين خادمًا.
المفهوم الرئيسي هو . البرمجيات هي كل شيء. في الواقع، لكي لا تفقد مهنة مسؤول النظام أهميتها، تحتاج فقط إلى تغيير التركيز قليلاً. يعمل مسؤولو النظام في مجال الخدمات ويجب أن يكونوا قادرين على التواصل بشكل فعال مع المطورين، والعكس صحيح. كما يقولون، رأس واحد جيد، ولكن اثنين أفضل.
والتفصيل الأخير في هذه الآلية هو . يعد العمل مع Git إحدى المسؤوليات اليومية التقليدية لمسؤول النظام. يتم استخدام نظام التحكم في الإصدار هذا على نطاق واسع من قبل المطورين ومتخصصي DevOps وفرق Agile وغيرهم الكثير. إذا كان عملك مرتبطًا بدورة حياة البرنامج، فبالتأكيد ستعمل مع Git.
جيت لديه الكثير من الميزات. من المحتمل أنك لن تتعلم أبدًا جميع أوامر Git، ولكنك ستفهم بالضبط سبب كونها عنصرًا أساسيًا في التواصل والتعاون بين البرامج. تعد المعرفة الشاملة بـ Git مهمة جدًا إذا كنت تعمل ضمن فريق DevOps.
إذا كنت مسؤول النظام، فأنت بحاجة إلى دراسة Git بشكل أفضل، وفهم كيفية إنشاء التحكم في الإصدار وتذكر الأوامر الشائعة: حالة git، git الالتزام -m، git add، git pull، git Push، git rebase، git Branch، git diff و اخرين. هناك العديد من الدورات التدريبية والكتب عبر الإنترنت التي يمكن أن تساعدك على تعلم هذا الموضوع من الصفر وتصبح محترفًا بمهارات محددة. هناك أيضا رائعة ، لذلك لا يتعين عليك حشرها جميعًا، ولكن كلما استخدمت Git أكثر، أصبح الأمر أسهل.
اختتام
في النهاية، عليك أن تقرر ما إذا كنت بحاجة إلى أن تصبح متخصصًا في DevOps أو ما إذا كان من الأفضل أن تظل مسؤولاً عن النظام. كما ترون، هناك منحنى تعليمي لإجراء عملية الانتقال، ولكن كلما بدأت مبكرًا، كان ذلك أفضل. اختر لغة برمجة وتعلم أدوات مثل (التحكم في الإصدار)، (CI/CD، التكامل المستمر) و (التكوين والأتمتة). مهما كان الخيار الذي تختاره، لا تنس أنك بحاجة إلى التعلم وتحسين مهاراتك باستمرار.
المصدر: www.habr.com