عبد الصمد العماري

الأعضاء
  • المساهمات

    7
  • تاريخ الانضمام

  • تاريخ آخر زيارة

كل منشورات العضو عبد الصمد العماري

  1. لقد كان هناك دائمًا جدل مستمر حول ما إذا كنا بحاجة إلى توسيع مفهوم DevOps من أجل جلب الأمان بوضوح. بعد كل شيء، من الواضح أن DevOps كانت دائمًا اختزالًا لمجموعة واسعة من الممارسات الجديدة باستخدام أدوات جديدة (غالبًا ما تكون مفتوحة المصدر) ومبنية على ثقافات أكثر تعاونًا. ولم لا نتجه نحو DevBizOps لتحسين التوافق مع احتياجات السوق؟ أو DevChatOps للتشديد على نظام اتصال أفضل وأسرع؟ ومع ذلك، كما كتب جون ويليس في وقت سابق من هذا العام عند وقوفه على المصطلحات الخاصة بـالDevSecOps: "نأمل أنه في يوم من الأيام سنكون في عالم ليس علينا أن نستخدم فيه كلمة DevSecOps، وسيكون الأمن جزءًا لا يتجزأ من جميع مناقشات تقديم الخدمة. حتى ذلك اليوم، وفي هذه المرحلة، استنتاجي العام هو أنها مجرد ثلاث حروف جديدة (Sec). والأهم من ذلك أن الاسم يميز حقًا مشكلتنا في عالم لا نقوم فيه بعمل رائع في مجال أمن المعلومات." فلماذا لا نقوم بعمل رائع في مجال أمن المعلومات؟ وماذا يعني القيام بعمل رائع في سياق DevSecOps؟ لم نتمكن من القيام بعمل كبير في مجال أمن المعلومات على الرغم من (أو ربما بسبب) الإنتاج الواسع للبرامج المعقدة التي تعالج المشاكل الضيقة. لكننا أيضًا قمنا بعمل جيد بما فيه الكفاية خلال تلك الفترة عندما كان الدفاع ضد التهديدات يركز على تأمين محيط العمل فقط، وكانت اتصالات الشبكة محدودة، وكان معظم المستخدمين موظفين يستخدمون أجهزة توفرها الشركة. لا تصف هذه الظروف بدقةٍ حقيقة معظم المنظمات منذ عدة سنوات حتى الآن. لكن الحقبة الحالية، التي لم تجلب مفهوم DevSecOps فحسب، بل حتى الأنماط الهيكلية للتطبيقات الجديدة، وممارسات التطوير، وعدد متزايد من التهديدات، تحدد وضعًا طبيعيًا جديدًا وقاسيًا يتطلب وتيرة تغيير أسرع. ليس تغيير منظومة الأمان مرتبطا بالDevSecOps منعزلة، ولكن الأمر يتطلب أمنًا معلوماتيًا بمقاربات جديدة. أمعن النظر في هذه المجالات الخمسة. 1. الأتمتة (Automation) إن السمة المميزة لـ DevOps بشكل عام هي الأتمتة بأكبر قدر ممكن. ويتعلق الأمر جزئياً بالسرعة. إذا كنت ستتحرك بسرعة (دون الإضرار بالأشياء)، فستحتاج حتمًا إلى عمليات قابلة للتكرار تُنفذ دون تدخل بشري كبير. في الواقع، تعد الأتمتة مدخلًا مهمًا لـDevOps، حتى في المؤسسات التي لا تزال تعمل في الغالب على التطبيقات القديمة المتجانسة. وتمثل أتمتة العمليات الروتينية المرتبطة بالتكوينات أو الاختبارات باستخدام أدوات سهلة الاستخدام مثل Ansible دفعةً سريعةً لبدء الطريق إلى DevOps. ليست DevSecOps مختلفة عن هذا المفهوم، فالأمن اليوم هو عملية مستمرة وليس نقطة تفتيش منفصلة في دورة حياة التطبيق، أو حتى فحصًا أسبوعيًا أو شهريًا. عندما يُعثر على الثغرات ويُصدر البائع إصلاحاته، يكون من المهم أن تُطبّق بسرعة لكي تنتهي عمليات استغلال هذه الثغرات الأمنية قريبًا. 2. التحرّك نحو اليسار (Shift left) غالبًا ما يُنظر إلى الأمن التقليدي كحارس بوابة في نهاية عملية التطوير. افحص جميع الصناديق وسيمرّ تطبيقك إلى مرحلة الإنتاج وإلّا حاول مرة أخرى. تُعرف فرق الأمن بأنها لا تكثر الكلام. وبالتالي، لم لا نحرك الأمن مبكرًا نحو اليسار (في الرسم النموذجي من اليسار إلى اليمين لمسلسل التطوير)؟ قد يصرّ الأمنيون على الرفض، ولكن عواقب إعادة الصياغة في مرحلة مبكرة من التطوير هي بالتأكيد أقل بكثير مما يكون عليه الحال عندما يكون التطبيق كاملًا وجاهزًا للتسليم. لا أحب مصطلح "التحرّك نحو اليسار" فذلك يعني أن الأمان لا يزال مجرّد حدثٍ لمرة واحدة نُقل لمرحلة مبكّرة. يجب أن يكون الأمان عملية مؤتمتة إلى حد كبير في كل مكان في دورة حياة التطبيق، من سلسلة التوريد إلى عملية التطوير والاختبار على طول الطريق حتى النشر. 3. إدارة التبعيات (Manage dependencies) أحد التغييرات الكبيرة التي نراها في تطوير التطبيقات الحديثة هو أنك غالبًا لا تكتب معظم الكود. ويعدّ استخدام المكتبات والأطر مفتوحة المصدر مثالًا واضحًا على ذلك. لكن يمكنك أيضًا استخدام الخدمات الخارجية من موفري الخدمات السحابية العامة أو مصادر أخرى. في كثير من الحالات، ستغطي هذه الأكواد والخدمات الخارجية على ما تكتبه بنفسك. نتيجة لذلك، تحتاج منظومة DevSecOps إلى تركيز جادٍّ على سلسلة التوريد الخاصة بالبرنامج. هل تحصل على برنامجك من مصادر موثوقة؟ هل هو مُحدّث؟ هل هو مدمج في عمليات الأمان التي تستخدمها لكودك الخاص؟ ما هي السياسات التي تطبقها في أيّ أكوادٍ وأيّ واجهات لبرمجة التطبيقات قد تستخدمها؟ هل يتوفر الدعم التجاري للمكونات التي تستخدمها لشيفرة المنتج الخاص بك؟ لن تكون هناك مجموعة من الإجابات تناسب جميع الحالات. قد تكون مختلفة في حالة "إثبات الجدوى" عنها في حالة الإنتاج على نطاق واسع. ولكن، كما كان الحال في التصنيع لفترة طويلة (هناك العديد من أوجه الشبه بين DevSecOps وكيفية تطور التصنيع)، تبقى سلامة سلسلة التوريد أمرًا بالغ الأهمية. 4. الرؤية (Vision) لقد تحدثت كثيرًا عن الحاجة إلى الأتمتة خلال جميع مراحل دورة حياة التطبيق. هذا يجعلنا نفترض أنه يمكننا رؤية ما يجري في كل مرحلة من تلك المراحل. تتطلب منظومة DevSecOps الفعالة بالضرورة أدوات فعالة حتى يتضح ما يجب على الأتمتة أن تقوم به. وتندرج هذه الأدوات في عدد من الفئات. هناك مقاييس طويلة الأمد وعالية المستوى تساعدنا في معرفة ما إذا كانت عملية DevSecOps الشاملة تعمل بشكل جيد. وهناك أدوات إنذار حساسة تتطلب تدخلًا بشريًا فوريًا (إذا كان نظام المسح الأمني معطّلًا!). وهناك إنذارات، مثل الفحص الفاشل، تتطلب علاجًا أو إصلاحًا. وهناك سجلات للعديد من البارامترات التي نلتقطها من أجل التحليل لاحقًا (ما الذي يتغير بمرور الوقت؟ وما الذي يتسبب في هذا الفشل؟). 5. الخدمات مقابل الوحدات المتراصة رغم أنه يمكن تطبيق ممارسات DevSecOps على العديد من هياكل تصميمات التطبيقات، إلا أنها تكون أكثر فاعلية من خلال المكونات الصغيرة والموضوعة بشكل فضفاض يتيح تحديثها وإعادة استخدامها دون فرض تغييرات في أماكن أخرى من التطبيق. يمكن أن تكون هذه المكونات في أنقى صورها خدمات مصغرة أو وظائف، لكن المبادئ العامة تنطبق حيثما كان لديك خدمات مقترنة بشكل فضفاض تتواصل عبر الشبكة. يقدم هذا النمط بعض التحديات الأمنية الجديدة. يمكن أن تكون التفاعلات بين المكونات معقدة ويمكن أن تكون المساحة المعرّضة للهجوم أكبر لأن هناك الآن المزيد من نقاط الدخول إلى التطبيق عبر الشبكة. من ناحية أخرى، يدلّ هذا النمط من الهياكل على أن الأمن والمراقبة الآليين يتمتعان أيضًا برؤية أكثر دقة لمكونات التطبيق لأنها لم تعد مدفونة بعمق داخل تطبيق متراصٍّ. لا تنغمس كثيرًا في مصطلح DevSecOps، ولكن عليك أن تتذكر أن الأمن يتطور لأن الطريقة التي نكتب بها وننشر التطبيقات تتطور. ترجمة وبتصرف للمقال ‎5 ways DevSecOps changes security لغوردون هاف
  2. يعرف كل مطور أهمية اتباع أفضل ممارسات الأمان. لكننا في كثير من الأحيان نتصرف باقتصاد ولامبالاة، ربما لأنه يتعين علينا العمل بجد حتى تترسخ تلك الممارسات الأمنية. لسوء الحظ، يكون هذا مثل رؤية سلوك أمني سيء جدًا لدرجة لا يُمحى فيها من أدمغتنا. لقد رأيت الكثير من حالات ممارسات الأمان السيئة أثناء مسيرتي مديرًا للأنظمة، لكن الأمور الثلاثة التي سأصفها هنا أساسية ويجب على كل مطور برمجيات تجنبها. من المهم الإشارة إلى أنني رأيت الشركات الكبيرة والمطورين ذوي الخبرة يرتكبون هذه الأخطاء، لذلك لا يمكنك أن تربط هذه الأخطاء بالمهندسين المبتدئين. 1. لا تشفر كلمات المرور، بل جزّئها في وقت سابق من حياتي المهنية، عملت لدى شركة تستخدم نظامًا إداريًا يحتوي على بعض المعلومات المهمة. في أحد الأيام، طُلب مني إجراء مراجعة أمنية للشبكة والبرنامج الذي يُخزّن معلوماتنا المهمة. أمضيت بضع دقائق في التجول قبل أن أقرر استخدام برنامج وايرشارك لتحليل حركة المرور في الشبكة. استخدمت جهازي المحلي، وسجلت الدخول إلى نظام المعلومات، فلاحظت شيئًا غريبًا. على الرغم من أن هذا كان قبل انتشار بروتوكول SSL، إلا أنني لم أتوقع أن أرى البيانات بنص عادي يحتوي على بايتات مثل "اسم المستخدم" و "كلمة المرور". عند الفحص الدقيق، بدا أن النظام كان يرسل اسم المستخدم الخاص بي وسلسلة عشوائية، لم تكن كلمة المرور الخاصة بي، عبر الشبكة. لم أستطع ترك الأمر كذلك. لقد حاولت تسجيل الدخول مرة أخرى، إلا أنه في هذه المرة أدخلت كلمة المرور الخاصة بي خاطئة عن قصد. لم أغيرها كاملة، بل حرفا واحدًا فقط. ما كنت أتوقعه هو سلسلة عشوائية مختلفة تمامًا تمثل كلمة المرور. بدلاً من ذلك، تغيّر البايتان الأولان فقط. كان هذا مثيرًا للاهتمام. على الرغم من أنني كنت قليل الخبرة نسبيًا، فقد علمت أنه إذا تجزّأ تمثيل كلمة المرور الخاصة بي كما كان مفترضًا، فسيكون الأمر مختلفًا تمامًا، ولن يكون الاختلاف في حرفين فقط. تبًّا، فحتى مخطط تشفير جيد سيفعل ذلك. لكن هذا، مع ذلك، لم يفعل ذلك على الإطلاق. لقد جربت مرتين أخريين كلمات مرور خاطئة. أمضيت الساعتين التاليتين مسلّحا ببعض الأوراق وقلم رصاص في اكتشاف مخطط فك التشفير. في نهاية الساعتين، كان لديّ نص بايثون يمكن أن يأخذ أي كلمة مرور "مشفرة" ويفك تشفيرها للكشف عن كلمة المرور الأصلية، وهو أمر لا ينبغي لأحد أن يفعله. أنا متأكد من أن الشخص الذي تخيل مخطط التشفير هذا لم يفكر أبدًا في أن شخصًا ما سوف يجلس ساعتين ويستطيع حلّه، لكنني فعلت ذلك. لماذا؟ لأنني أستطيع ذلك. إذا كان عليك تخزين كلمات المرور للمقارنة، فلا تشفرها مطلقًا إذ يُحتمل دائمًا أن يجد شخص ما خوارزمية أو مفتاح فك التشفير. ليس للتجزئة (hash) انعكاس مباشر، مما يعني أنه لا يمكن لأحد عكسها ما لم يكن لديه بالفعل جدول مع التعيين من النص العادي إلى التجزئة (أو أن يخمنه ببساطة). لا تؤثر معرفة آلية التجزئة على سلامة البيانات، بينما يضر بها انكشاف مخطط ومفاتيح التشفير. 2. لا تضع أبوابا خلفية سرية في البرنامج كجزء من متابعة برنامج تابع لجهة خارجية، كنت أدعم بعض المستخدمين الذين أخبروني أن تسجيلات الدخول الخاصة بهم لا تعمل. كانت هذه خدمة مدفوعة الأجر مقدمة من بائع، لكن قبل أن أتعامل مع أحد كانت أكثر مكالمات الدعم إزعاجًا تحت عنوان "لا يعمل تسجيل الدخول الخاص بي"، اعتقدت أنني سأحاول ذلك بنفسي. لقد كان الأمر صحيحًا، لم تعمل تسجيلات الدخول. كان النظام عبارة عن منصة لإدارة التعلم عبر الإنترنت، والتي دفعنا مقابلها جزءًا صغيرًا من قدراتها الكبيرة. عندما بحثت بفضول في صفحة تسجيل الدخول، لفت انتباهي شيء ما. بدا لي حرف واحد في إحدى الكلمات مختلفًا. ربما كان خطًا مختلفًا للكتابة، أي شكلًا مختلفًا قليلاً لحرف "o". ولأنني أنا دون غيري، فتحت الصفحة بطريقة عرض المصدر، ولاحظت وجود رابط مرتبط بهذا الحرف المحدّد. لقد أُخفي الرابط عن قصد بحيث لا يتغير مؤشر الفأرة عند التمرير فوقه. لهذا حمّلت هذا الرابط الغامض بحذر شديد في نافذة متصفح جديدة. وفجأة ، قابلتني شاشة تعرض بالتفصيل مجموعة كاملة من أجهزة الحواسيب، وتمنحني سيطرة كاملة على ما يمكنها القيام به والقدرة على إيقاف تشغيلها، وإعادة تشغيلها، وأخذ لقطات للشاشة، سمِّها ما شئت. اتصلت ببائع البرنامج وطلبت التحدث إلى تقني المعلومات. بعد المرور على بعض الأشخاص، وصلت أخيرًا إلى شخصٍ يعرف مسبقًا ما الذي كنت أتحدث عنه. قال لي: "أوه نعم! لقد وضعنا ذلك في مكان يسهل الوصول إليه، ولم يعثر عليه أحد حتى الآن قبلك. سنقوم بإزالته على الفور". قبل أن ننهي المكالمة، سألني سؤالًا أخيرًا:" لماذا بدأت تبحث في HTML؟". كانت إجابتي بسيطة: "لأنني أستطيع". إن الأمر لا يستحق المخاطرة بوضع منفذٍ خلفيٍّ جميلٍ في أي نظام، لأنك قد تراهن بآخر دولار لديك وسيجده شخص ما. بغض النظر عن مدى الغموض، غالبًا ما يؤدي تحليل الشفرة، وحتى البحث الفضولي السطحي، إلى أكثر النتائج غرابةً وإثارة للاهتمام. 3. فعِّل تصديق هوية المستخدمين في كل صفحة، وليس فقط على صفحة تسجيل الدخول في مرحلة ما من حياتي المهنية، شاركت في مشروع لتطوير البرمجيات نفّذه مطوّر متمرس. بعد أن شعرت قليلاً بقلّة الحيلة أمام هذا التطبيق المميز، أخبرت مديري أننا سنحتاج إلى مراجعة أمنية معمقة للشيفرة. وطُلب مني النظر على أي حال لمعرفة ما يمكن أن أجده. بدأت اللعب مع التطبيق، وسجلت الدخول، وعرضت بعض البيانات. ثم وجدت شيئًا مثيرًا للاهتمام حقًا. إذا وضعت إشارة مرجعية على أحد عناوين URL التي ألج إليها كثيرا في النظام، فيمكنني فقط نسخها ولصقها في متصفح آخر، وقضي الأمر! سأكون هناك دون الحاجة إلى تسجيل الدخول. سألت المطور: "لماذا لا تُسجّل الدخول في كل صفحة؟ إذا أدخلت عنوان URL لصفحة ما في النظام، فيمكنني الوصول إليها دون تسجيل الدخول". فسألني: "لماذا تفعل ذلك؟". أجبته: "لأنني أستطيع". لا تترك أي شيء للصدفة حتى المطورون المتمرسون قد يرتكبون هذه الأخطاء. يعتقدون أن لا أحد سيحاول مطلقًا الخوض في نظام لا يستطيع الوصول إليه فعليًا. المشكلة هي أن الناس سوف يبحثون بفضول، وسوف يحفرون. نصيحتي الجوهرية التي أود أن أنقلها هنا لأي شخص مهمته مراعاة الأمان فقط هي: لا تترك أي شيء للصدفة. هناك أشخاص مثلي، يحبون الحفر في الأشياء ومعرفة علّة وكيفية عملها. ولكن هناك أيضًا عدد كبير من الأشخاص الذين سيحفرون لاستغلال عيوبك ونقاط ضعفك. لماذا؟ لأنهم يستطيعون! ترجمة وبتصرف للمقال ‎3 security tips for software developers لبيت سافايج
  3. أنت تعمل على الانتقال إلى منظومة DevOps وتطبيقها في مؤسستك بالكامل أو في جزءٍ منها فقط: حسنًا! ها قد حقّق شخص ما في مكان ما قفزة نوعية. لنفترض، لأغراض هذا المقال، أن لديك موافقة من الإدارة: مهما كانت العقبات التي ينبغي عليك تجاوزها وكيفما كانت الجبال التي تحتاج لتسلقها للحصول على ذلك الجواب بـ "نعم". لقد حصلت على موافقة على الأدوات ووضعت كل الإجراءات والعمليات على الطاولة، والآن كل ما عليك القيام به هو إقناع الناس بالاندماج في المنظومة. يجب أن يكون هذا الأمر سهلا، أليس كذلك؟ نتمنى لو يكون كذلك. يتضح أنه ليس كل الناس مستنيرين مثلك أنت قارئ هذا المقال. لا يحب الناس كلّهم التغيير، وإذا كان هناك شيء واحد يمكنك التأكد منه، فهو هذا الأمرُ. ستحقق منظومة DevOps التغيير لمؤسستك: كيف عليك أن تعمل؟ وماذا تفعل؟ وكيف تتفاعل مع الأشخاص الآخرين داخل الفريق وخارجه؟ سوف أَصِفُ هنا خمسة أنواع من الأشخاص أو الأدوار الذين قد يعارضون عملية الانتقال إلى DevOps، كما سأعرض بعض الأفكار حول التكتيكات الممكنة للمساعدة في تحفيزهم للاندماج فيها. ومع ذلك، يجب أن نتذكر أنك قد لا تتمكن من تعبئة الجميع، وقد تكون هناك أسباب وجيهة لعدم رغبة الناس في تغيير ما يقومون به، بما في ذلك حقيقة أن ما يقومون به في الوقت الحالي قد يعمل بشكل جيد، سواء بالنسبة لهم أو للمنظمة. هذا لم يُخترَع من أجلنا: الخوف من المجهول "لقد فعلنا هذا على مدار الأعوام الماضية (سنة أو سنتان أو خمس أو عشر أو خمس وعشرون سنة)، وكان هذا الأمر ينجح دائمًا حتى اليوم". لقد سمعنا جميعًا عبارات كهذه. وقد يكون هذا صحيحًا أو قد لا يكون كذلك، ولكن إذا قررت إدارتك أنه يجب إجراء الانتقال إلى DevOps حتى لو كانت الممارسات الحالية تعمل، فمن الأرجح أن يكون هناك إدراك أن الأمور يمكن أن تكون أكثر كفاءةً أو سرعةً أو أمانًا. إن إحدى النقاط المُحدِّدَة لهذا النوع من الأشخاص أو الأدوار هي أنه يتصرف في كثير من الأحيان كفريق. وغالبًا ما تعتاد الفرق على طريقة معينة للقيام بالأشياء وعلى استقرار في الأدوار والروتينات التي تناسبها. وبالتالي فما تقترحه أنت هنا يمثل إزعاجًا للفريق ويجعل الناس يفعلون أشياء مختلفة. يجب أن تفكر في كيفية تحقيق أقصى استفادة من الفريق كما هو موجود الآن، أو ربما بنقل أعضاء ذلك الفريق معًا أو بإبداء نوع من الاحتفال بنجاحهم، بدلاً من اقتراح التغيير و تعليله بأنهم فشلوا بطريقة أو بأخرى. مجالي: الخوف من فقدان السيطرة هذا نوع من الأشخاص أعرفه تمامًا على المستوى الشخصي بحكم خلفيتي الأمنية. غالبًا ما يشعر الأشخاص الذين حصلوا على مستوى عالٍ من الخبرة في ميدان أو مجال معين بالتهديد عندما يُطلب منهم تغيير طريقة عملِهم أو تطبيقِ معارفهم. سيشعرون غالبًا بأنهم مطالبون بالتخلي عن السيطرة و بـ "تخفيف" خبراتهم في عالم جديد فيه "كلّ شخص هو الخبير". ما يهمّ التأكيد عليه في هذا السياق هو أنه بدلاً من تخفيف خبراتهم، تعدّ هذه فرصة لتطبيقها على مجموعة واسعة من العمليات. ينبغي على خبراء الاختبار أن يشرحوا للمطورين وأفراد العمليات، على سبيل المثال، كيف يمكن عرض منهجيات الاختبار في مجالاتهم. عادةً ما ينظر الخبراء بإيجابيةٍ إلى مسألة عرضهم أمام جمهور أوسع، وعلى الرغم من أنه سيكون هناك دائمًا شخصيات من نوع "البرج العاجي" تكافح من أجل التفاعل في إطار أكثر جماعية، فإن استخدام هؤلاء بطرق يأخذون فيها دور "الاستشاري" قد يوفر فرصًا إيجابيةً. متشبث بأسلوبي: الخوف من الجديد رغم أنه يشبه إلى حد بعيد شخصية "لم يخترع من أجلنا"، إلا أنه يعد فردًا أكثر من كونه سمة جماعية. قد تبدو معرفة ما ستكون عليه مهامك على أساس يومي تافهة للبعض ولكنها قد تكون مريحةً للغاية بالنسبة للكثيرين، وهذا هو السبب في أنهم قد لا يرغبون في الانتقال إلى عالم يبدو "أكثر حرية" وغير منظّمٍ. لا يمكن أن يكون الجميع مثل ذلك النوع من الموسوعيين الذين ينجحون في فهم جميع الأجزاء المختلفة من دورة DevOps. الخبر السار هنا هو أنك ستظل بحاجة إلى أشخاص مستعدين للاستقرار في مهام محددة وإكمالها بطرق معينة. في الواقع، على الرغم من وجود مخاوف مبدئية حول الانتقال إلى بيئة مختلفة للعمل، فإن توضيحك لأعضاء الفريق أنه سيكون لديهم قدر لا بأس به من التحكم في كيفية أدائهم لمهام معينة قد يكون رسالةً إيجابيةً عند محاولة مساعدة هذا النوع من الأفراد. ونأمل أن يساهم تضمينك للتدريب، رسميًا كان أو غير رسمي، كجزء من تحولك إلى DevOps وكذا الفرص المتاحة لتعلم مهارات جديدة (وبالتالي زيادة حركية الأفراد وفرص العمل) أيضًا كحوافز للتغيير. مدراء الأفراد: الخوف من فقدان السلطة يتمتع المديرون في العديد من المؤسسات، وخاصة تلك التي تتمتع بتسلسل هرمي قويٍّ ومتطوّرٍ، بقدر كبير من التحكم في كيفية انتشار موظفيهم وطبيعة مهامهم وكيفية إدارة تقدمهم الوظيفي. كل هذه الأمور يمكن أن تكون مباشِرة خلافًا لمقاربة DevOps التي تعدّ أكثر انفتاحًا. بالنسبة للمديرين الذين بنوا إمبراطوريتهم الصغيرة بالتحكم في تقاريرهم الرئيسية و الفرعية مثل البيادق حول لوحة الشطرنج، سيكون الانتقال إلى DevOps تحدّيًا كبيرًا. أما بالنسبة للمديرين الذين يحرصون على تطوير أعضاء فرقهم ليصبحوا موظفين أكثر خبرة، والذين يقيسون نجاحهم بعدد الفرق الأخرى التي تطلب إعارة تقاريرها إلى فرقهم، والذين يستمتعون كذلك برؤية مهارات جديدة وبالتقدم الوظيفي، ستكون DevOps بالتأكيد فرصةً مثيرةً. من الراجح أن يكون أسلوب العصا و الجزرة جزءًا من أي حلٍّ لمشكلة المديرين الذين يقاومون الإدارة التنفيذية. يمكن أن تتضمن الجزرة تغيير كيفية مكافأة المديرين وفقًا لآلية تتبنى هذه السلوكيات الجديدة، في حين قد تتضمن العصا تجريد فرقهم من بعض أعضائها أو إعادة تحديد دور هؤلاء المديرين. النقابات: الخوف من عدم اليقين في بعض المصانع والمناطق، هناك نقابات قوية. تتمثل المهمة الأساسية للنقابات في حماية العمال من الاستغلال من قبل الإدارة التي قد تحاول فرض تغييرات على العمال لن تعود عليهم بفائدة. تشتبه النقابات بشكل افتراضي ومفهومٍ كذلك في أي تغييرات تدخلها الإدارة، لذا فإن أي انتقال إلى DevOps تباركه الإدارة قد يثير مخاوف ومقاومة النقابات وأعضائها. في بعض الحالات، قد يكون الموظفون قد وصفوا بعناية أدوارهم الوظيفية التي تجعل من الصعب تقديم طرقٍ للعمل يتوقع منهم فيها القيام بدور أكثر موسوعيةً وتعلم مهارات جديدة، وهذان كلاهما من خصائص DevOps. والخبر السار هنا هو أن DevOps يمكن أن توفر المزيد من التحكم لأعضاء الفريق، بطرق مختلفة كثيرة، مما يقلل إلى حد ما من السيطرة التي تمارسها وظيفة الإدارة. سيكون توضيح ذلك والتأكد من إجراء عمليات الفحص المناسبة لحماية الوظائف أحد المفاتيح الرئيسية لإقناع النقابات وأعضائها بأن هذا تغيير جيد بالنسبة لهم. والشيء الآخر الذي كان يجب أن يحدث، بالطبع، هو أنه كان ينبغي على الإدارة إدماجهم مبكرًا في العملية للتأكد من انخراطهم من البداية، بدلاً من اتخاذ قرارٍ "نبت" فجأة في اللحظة الأخيرة. أفكار ختامية مع تقدمنا نحو مستقبل جديد مشرق، تجدر الإشارة إلى أن الخير العام للجميع لا يترجم دائمًا إلى تغيير إيجابي لكل فرد. يصعب القول أن بناء شبكات الصرف الصحي ليس خيرًا عامًّا، لكنه يؤذي من كانت وظيفتهم الحرص على نظافة الشوارع. نأمل ألا ترى انتقالك إلى DevOps كإنشاء مجموعة جديدة من شبكات الصرف الصحي لمؤسستك، ولكن انتبه إلى أولئك الذين قد يكون التغيير بالنسبة لهم صعبًا ومضطربًا. يمكن أن يكون هناك تكلفة بشرية لأي تطوير مهما حسنت نيته. بالنسبة لي، أهم نقطة ينبغي تذكرها هي أنه عندما يصبح الأشخاص دفاعيين، بل وأحيانًا عدوانيين، يكون ذلك عمومًا لأنهم يشعرون بالتهديد، وفي كل هذه الحالات التي فحصناها، قد يكون التغيير مهدِّدًا بالفعل. إن هؤلاء الناس هم زملاؤك. وهُم أناس أيضًا، ويجب معاملتهم باحترام وتقدير كأشخاص، وليس فقط كأدوار أو عقبات يتعين التغلب عليها. في بعض الحالات، قد يكون الحفاظ على الوضع الراهن في أجزاء خاصة من مؤسستك الخيار الأكثر أمانًا، في الوقت الحالي على الأقل. ترجمة وبتصرف للمقال Who will push back the most on a move to DevOps?‎ لمايك بورسيل
  4. عندما تُنشئ خادم أوبونتو 18.04 لأول مرة، فهناك بعض خطوات الإعداد التي ينبغي عليك اتخاذها مبكّرًا كجزء من الإعداد الأساسي. سيزيد ذلك من أمان الخادم وسهولة استخدامه وسيمنحك أساسًا قويًا لاتخاذ إجراءات لاحقة. رغم أنه يمكنك إكمال هذه الخطوات يدويًا، إلا أنه في بعض الأحيان يكون من الأسهل برمجة العمليات عبر سكربت لتوفير الوقت وتفادي الأخطاء البشرية. يشرح هذا الدليل كيفية أتمتة الخطوات الموجودة في دليل إعداد الخادم الأولي في سكربت. ماذا يفعل السكربت؟ يعدّ هذا السكربت بديلًا للتشغيل اليدوي من خلال الطريقة الموضحة في دليل إعداد خادم أوبونتو 18.04 الأولي ودليل إعداد مفاتيح SSH على أوبونتو 18.04. تؤثر المتغيرات التالية على كيفية عمل السكربت: USERNAME: اسم حساب المستخدم العادي الذي ستُنشأ وتمنح له صلاحيات sudo. COPY_AUTHORIZED_KEYS_FROM_ROOT: تحدّد ما إذا كنت تريد نسخ أصول مفتاح SSH من الحساب الجذري root إلى حساب sudo الجديد. OTHER_PUBLIC_KEYS_TO_ADD: مجموعة من السلاسل النصية التي تمثل مفاتيح عامة أخرى تُضاف إلى الحساب sudo. يمكن استخدام هذه بالاختيار بين إضافتها أو جعلها بديلًا لنسخ المفاتيح من الحساب الجذري root. يجب عليك تحديث هذه المتغيرات حسب الحاجة قبل تشغيل السكربت. عند تنفيذ السكربت، تُنفّذ الإجراءات التالية: إنشاء حساب مستخدم عادي مع امتيازات sudo باستخدام الاسم الذي يحدده المتغير USERNAME . إعداد إطار لكلمة المرور الأولية للحساب الجديد: إذا كان الخادم معدًّا لمصادقة الهوية بكلمة المرور، فستُنقل كلمة المرور الإدارية الأصلية التي وُلِّدت لحساب root إلى حساب sudo الجديد. حينها تكون كلمة المرور للحساب الجذري مقفلة. إذا كان الخادم معدًّا لمصادقة الهوية بمفتاح SSH، فستُعيّن كلمة مرور فارغة لحساب sudo. تُعلّم كلمة مرور المستخدم sudo بعلامة "منتهي الصلاحية" مما يوجب تغييرها عند أول تسجيل للدخول. يُنسخ ملف Authorized_keys من الحساب الجذري إلى مستخدم sudo إذا عُيِّن المتغير COPY_AUTHORIZED_KEYS_FROM_ROOT على "صحيح". تُضاف أي مفاتيح معرّفة في OTHER_PUBLIC_KEYS_TO_ADD إلى ملف Authorized_keys للمستخدم sudo. يُعطّل التصديق SSH المستند إلى كلمة المرور في الحساب الجذري root. يُفعّل جدار الحماية UFW مع السماح باتصالات SSH. كيف يُستخدَم السكربت؟ يمكن تنفيذ السكربت بطريقتين: عن طريق إضافته إلى حقل بيانات مستخدم الخادم أثناء الإنشاء أو عن طريق تسجيل الدخول بحساب root وتنفيذه بعد التشغيل. عبر بيانات المستخدم عند إنشاء Droplet على DigitalOcean، يمكنك تحديد بيانات المستخدم، وهو سكربت يُنفّذ أثناء تشغيل الخادم الأولي من أجل إجراء إعدادٍ إضافي. إذا كنت تُنشئ Droplet من لوحة التحكم، فيمكنك تحديد خانة الاختيار "بيانات المستخدم" في قسم تحديد خيارات إضافية. سيظهر لك مربع نصي حيث يمكنك لصق السكربت: إذا كنت تُنشئ Droplet باستخدام واجهة برمجة تطبيقات DigitalOcean، فيمكنك تمرير السكربت باستخدام سمة user_data بدلاً من ذلك. إذا كنت تُنشئ Droplet باستخدام أداة سطر الأوامر doctl، فيمكنك تمرير السكربت باستخدام خيار ‎--user-data-file: $ doctl compute droplet create ... --user-data-file /path/to/script بغض النظر عن الطريقة التي تستخدمها لإضافة بيانات المستخدم، سيُنفّذ السكربت في أول مرة يُشغّل فيها الخادم الجديد. قد تضطر إلى الانتظار لبضع دقائق حتى تكتمل العملية، ولكن بعد ذلك، يمكنك تسجيل الدخول إلى الخادم الخاص بك عبر حساب المستخدم sudo للحصول على أي إعداد إضافي. عند تسجيل الدخول لأول مرة، سيُطلب منك تغيير كلمة المرور الخاصة بك. سينهي الخادم جلسة SSH الحالية بمجرد تقديم بيانات الاعتماد الجديدة الخاصة بك وتأكيدها. بعد ذلك، يمكنك إعادة SSH مرة أخرى مثل العادة. تنفيذ السكربت بعد التشغيل إذا كنت لا ترغب في استخدام بيانات المستخدم، يمكنك أيضًا تشغيل السكربت يدويًا عبر SSH بمجرد تشغيل الخادم. إذا نزّلت السكربت على جهاز الكمبيوتر المحلي الخاص بك، يمكنك تمرير السكربت مباشرةً إلى SSH بكتابة ما يلي: $ ssh root@servers_public_IP "bash -s" -- < /path/to/script/file ينبغي أن تكون الآن قادرًا على تسجيل الدخول باستخدام حساب sudo الخاص بك من أجل أي إعداد إضافي. إذا لم تُنزّل السكربت على جهاز الحاسوب المحلي، فابدأ بتسجيل الدخول إلى الحساب root على الخادم الخاص بك: $ ssh root@servers_public_IP بعد ذلك، نزِّل السكربت الأولي على الخادم: $ curl -L https://raw.githubusercontent.com/do-community/automated-setups/master/Ubuntu-18.04/initial_server_setup.sh -o /tmp/initial_setup.sh افحص السكربت للتأكد من تنزيله بشكل صحيح و حدِّث أي متغيرات ترغب في تغييرها: $ nano /tmp/initial_setup.sh عندما تكون راضيًا عن المعطيات، شغّل السكربت يدويًا باستخدام bash: $ bash /tmp/initial_setup.sh ينبغي أن تكون الآن قادرًا على تسجيل الدخول باستخدام الحساب ذي الصلاحيات sudo لإتمام أي إعدادٍ إضافي. محتويات السكربت يمكنك العثور على السكربت لإعداد الخادم الأولي في مخزن الإعداد التلقائي لمؤسسة DigitalOcean Community GitHub. لنسخ محتويات السكربت أو تنزيلها مباشرةً، انقر فوق الزر (Raw) أعلى النص، أو انقر هنا لعرض المحتويات الأولية مباشرة. لقد أدرجت المحتويات كاملة أيضًا هنا لتسهيل العملية: #!/bin/bash set -euo pipefail ######################## ### SCRIPT VARIABLES ### ######################## # اسم حساب المستخدم العادي الذي ستُنشأ وتمنح له صلاحيات # Name of the user to create and grant sudo privileges USERNAME=sammy # الجديد sudo إلى حساب root من الحساب الجذري SSH تحدّد ما إذا كنت تريد نسخ أصول مفتاح # Whether to copy over the root user's `authorized_keys` file to the new sudo # user. COPY_AUTHORIZED_KEYS_FROM_ROOT=true # sudo مجموعة من السلاسل النصية التي تمثل مفاتيح عامة أخرى تُضاف إلى الحساب # Additional public keys to add to the new sudo user # OTHER_PUBLIC_KEYS_TO_ADD=( # "ssh-rsa AAAAB..." # "ssh-rsa AAAAB..." # ) OTHER_PUBLIC_KEYS_TO_ADD=( ) #################### ### SCRIPT LOGIC ### #################### # ومنحه الصلاحيات sudo إنشاء حساب المستخدم # Add sudo user and grant privileges useradd --create-home --shell "/bin/bash" --groups sudo "${USERNAME}" # تحقق من توفّر الحساب الجذري على كلمة مرور # Check whether the root account has a real password set encrypted_root_pw="$(grep root /etc/shadow | cut --delimiter=: --fields=2)" if [ "${encrypted_root_pw}" != "*" ]; then # تُنقل كلمة المرور الإدارية الأصلية التي وُلِّدت لحساب الجذري إلى الحساب الجديد. حينها تُقفل كلمة المرور للحساب الجذري # Transfer auto-generated root password to user if present # and lock the root account to password-based access echo "${USERNAME}:${encrypted_root_pw}" | chpasswd --encrypted passwd --lock root else # حذف كلمة مرور غير صالحة للمستخدم في حالة استخدام المفاتيح بحيث يمكن تعيين كلمة مرور جديدة دون تقديم قيمة سابقة # Delete invalid password for user if using keys so that a new password # can be set without providing a previous value passwd --delete "${USERNAME}" fi # إنهاء صلاحيات المستخدم العادي لإجباره على تغييرها # Expire the sudo user's password immediately to force a change change --lastday 0 "${USERNAME}" # sudo للمستخدم SSH إنشاء مجلد # Create SSH directory for sudo user home_directory="$(eval echo ~${USERNAME})" mkdir --parents "${home_directory}/.ssh" # نسخ ملف المفاتيح من الحساب الجذري إذا كان ضروريًا # Copy `authorized_keys` file from root if requested if [ "${COPY_AUTHORIZED_KEYS_FROM_ROOT}" = true ]; then cp /root/.ssh/authorized_keys "${home_directory}/.ssh" fi # إضافة المفاتيح الإضافية المتوفرة # Add additional provided public keys for pub_key in "${OTHER_PUBLIC_KEYS_TO_ADD[@]}"; do echo "${pub_key}" >> "${home_directory}/.ssh/authorized_keys" done # SSH ضبط تكوينات ملكية وصلاحيات # Adjust SSH configuration ownership and permissions chmod 0700 "${home_directory}/.ssh" chmod 0600 "${home_directory}/.ssh/authorized_keys" chown --recursive "${USERNAME}":"${USERNAME}" "${home_directory}/.ssh" # إيقاف تسجيل الدخول للحساب الجذري باستعمال كلمة المرور # Disable root SSH login with password sed --in-place 's/^PermitRootLogin.*/PermitRootLogin prohibit-password/g' /etc/ssh/sshd_config if sshd -t -q; then systemctl restart sshd fi # SSH بعد إضافة استثناءات UFW تفعيل جدار الحماية # Add exception for SSH and then enable UFW firewall ufw allow OpenSSH ufw --force enable خاتمة يمكن أن يوفر لك إعداد الخادم الأولي تلقائيًا بعض الوقت ويمنحك أساسًا جيدًا لمزيد من الإعداد. إذا كانت هناك خطوات إضافية ترغب في اتخاذها، فيمكنك إما تسجيل الدخول بعد تشغيل السكربت للمتابعة يدويًا، أو إضافة الخطوات في نهاية السكربت لأتمتة العملية. ترجمة -وبتصرف- للمقال Automating Initial Server Setup with Ubuntu 18.04 لصاحبه Justin Ellingwood
  5. لا يدرك معظم الناس1 تمامًا مقدار المتعة التي في الأمان، أو بالضبط كيف تجعلك الخبرة الأمنية مثيرًا بالنسبة للأشخاص الآخرين2. نحن نعلم أنها شيقة وجذابة وممتعة، لكنهم لا يعلمون ذلك. لهذا السبب، عندما يتوجه مسؤولو الأمن إلى الأشخاص الآخرين (دعنا نسميهم "أشخاصًا عاديين" لأغراض هذه المقالة)، ويقولون لهم إنهم يفعلون شيئًا خاطئًا، ولا يمكنهم إطلاق منتجهم، أو نشر طلباتهم، أو أنه يجب عليهم التوقف عن استلام طلبات المبيعات على الفور وربما خلال اليومين المقبلين حتى يتم إصلاح ذلك، عندها قد لا يتفاعل هؤلاء الأشخاص العاديون دائمًا بمستوى الامتنان الذي نعتقد أنّه مناسب. في بعض الأحيان، في الواقع، سيعرضون ردودًا سلبية، قد تكون حتى شخصية، على هذه الاقتراحات. تكمن المشكلة في أنّ أفراد الأمن يعرفون كيف ينبغي أن تكون الأمور، و هذا آمن. لقد تلقوا التدريب وحضروا الدورات وقرأوا المقالات وتصفحوا الكتب الأمنية الضخمة3، وكل هذه المصادر تؤكّد بوضوح تامٍّ: يجب أن يكون كل شيء آمنًا. تعني كلمة "آمن" عمومًا "مغلقًا"، خاصة إذا كان أفراد الأمن لم يشاركوا بشكل كاف في إجراءات التصميم والتنفيذ والعمليات. يريد الناس العاديون، من ناحية أخرى، فقط أن تعمل الأشياء. هناك انفصال جوهري بين وجهتي النظر هاتين لأننا لن نستطيع الإصلاح إلا إذا كان الأمن هو المطلب الأساسي لأي مشروع من بدايته وحتى نهايته4. ليس الأشخاص العاديون الآن أغبياء. إنهم يعلمون أن الأمور لا تعمل دائمًا بشكل مثالي؛ لكنهم يرغبون في عملها أكبر قدر ممكن. وهذه هي الفجوة التي نحتاج إلى تخطيها. لقد تحدثت من قبل عن التدهور المُتحكّم فيه كمفهوم، وهذا جزء من القصة. أحد الأشياء التي ينبغي لأفراد الأمن أن يكونوا مستعدين للقيام بها هو توضيح أن هناك مخاطر يمكن التخفيف منها. بالنسبة لأفراد الأمن، يجب التخفيف من هذه المخاطر من خلال "الإغلاق". إنّه من السهل إيقاف الخطر إذ يمكنك فقط إيقاف تشغيل النظام، ولن يوجد خطر من إساءة استخدامه. ولكن بالنسبة للعديد من الأشخاص، هناك مخاطر أخرى: مثال على ذلك أن المؤسسة قد تتوقف في الواقع عن العمل تمامًا لأن بعض أفراد الأمن قد أغلقوا نظام الطلبات. إذا كانوا قد عرضوا عليّ خيار الموازنة بين مخاطرة التوقف عن تلقي الطلبات مقابل مخاطرة فقدان بعض بيانات الشركة الداخلية، فهل كنت سأقوم بالمخاطرة الأولى؟ حسنا نعم، قد أقدم عليها. ولكن إذا لم يُقدّم لي الاختيار، ولم تُوضّح لي المخاطرة، فلن يكون لدي خيار. هذا هو نوع الكلمات التي أودّ سماعها إذا كنت أدير أعمالًا. ليس هذا فقط هو نوع المخاطر الممكنة. فأن تأتي مثلًا إلى اجتماعِ المشروع قبل أسبوعين من إطلاقه وتعلن أنه لا يمكن نشر المشروع "لأن المحادثات على واجهة برمجة التطبيقات هذه تتم دون تصديق على الهوية" ليس أمرًا جيّدًا على الإطلاق لأي أحد. باعتباري مطوّرًا، فلديّ على أيّة حال مفردات مختلفة وهواجس مختلفة عن تلك الخاصة بمالك العمل. ماذا لو أنه بدلًا من العبارة التالية: "تحتاج إلى استخدام التّصديق على الهوية على واجهة برمجة التطبيقات هذه وإلّا لن تستطيع المتابعة"، يطرح مسؤول الأمان السؤال كالتالي: "ماذا سيحدث إذا كانت البيانات التي تُقدّم على واجهة برمجة التطبيقات هذه غير صحيحة، أو يقدّمها شخص ينوي تعطيل عمل النظام؟" وفقًا لتجربتي ، يهتمّ معظم المطورين ويلتزمون بالتشغيل الصحيح للنظام الذي يعملون عليه والبيانات التي يعالجها. في الغالب، تثير الأسئلة التي تُظهر التأثير المحتمل لانعدام الأمن ردود فعل إيجابية أكثر من "مناقشة" بدائية تنتهي أساسًا بالرفض. لا تفهمني خطأً؛ إن هناك أوقاتًا نحتاج فيها، كأفراد أمن، لأن نكون حازمين ومتشبثين بأسلحتنا5. ولكن في النهاية، فإن مالكي الأنظمة أو المنظمات أو وحدات الأعمال أو الموارد هم الذين يتخذون القرار النهائي. إن مهمتنا هي التحدث إليهم بكلمات يمكنهم فهمها والتأكد من أنهم مطلعون جيدًا قدر الإمكان و نتفادى أن يكون جوابهم مجرد "لا". أعني بذلك "أولئك المساكين الذين لا يقرؤون هذه المنشورات، على عكسك، عزيزي القارئ الذكي". يبدو أن زوجتي، للأسف، تندرج في هذه الفئة. الكتب التي عادة ما يكون على غلافها صورة قفلٍ. ونتمنى لك التوفيق في ذلك. مجازًا فقط، فأنا لا أقبل نقل أي أسلحة إلى مكان العمل بما في ذلك الأسلحة النارية. ترجمة وبتصرف للمقال Talking to normal people about security لمايك بورسيل
  6. في خضم السباق المحموم نحو الرقمنة، أصبحت فرق التطوير تمثّل العمود الفقري للعديد من المؤسّسات. لقد أصبح يتعين على أفرادها إلى جانب فرق العمليات القيام بمهمّات أكثر من أي وقت مضى. غالبًا ما تقود هذه الفرق الابتكار والتغيير في نفس الوقت الذي تحافظ فيه على النظام القديم وتضمن أداء المنتجات أو الخدمات باستمرار. إن المؤسّسات التي تسمح لفرق التطوير والعمليات لديها بالمرونة والسرعة في التحرك واستثمار الفرص تكون في الغالب مؤسّسات ناجحة، وهذا ما يجعل العديد من المنظمات تعطي الأولوية لبناء وتعزيز ثقافة DevOps. تجمع ثقافة DevOps بين فريق التطوير (DEVelopment) وفريق العمليات (OPerationS) في هيكل واحد سعياً لإنشاء البرامج بسرعة و بأقل نسبة من الأخطاء. إن ثقافة DevOps هي تحوّل كبير من الثقافة التقليدية لتكنولوجيا المعلومات؛ فبدلاً من أن يعمل فريقا التطوير والعمليات بشكل منفصل، تسهّل ثقافة DevOps التواصل بينهما من خلال جعلهما يعملان على أهداف مشتركة. ويتطلب الأمر أن يفهم كل منهما الأهداف ويتمكّنا من العمل سويًا لإنجاح الأعمال. يمكن أن تساهم الثقافة السليمة لدى فريق DevOps في عوائد ضخمة للمؤسسة. أفادت دراسة شملت 4600 فريق لتكنولوجيا المعلومات أن أولئك الذين يتبنون ثقافة DevOps نشروا برامج أكثر مائتي مرة من الفرق ذات الأداء المنخفض. لقد أمضوا نصف الوقت اللازم فقط لإصلاح مشكلات الأمان، وحققوا زمن استردادٍ أقلّ لبرامجهم ، وكان معدل فشل التغيير لديهم أقلّ ثلاث مرات. وبالتالي، يمكن لجميع المنظمات تقريبًا أن تجد بعض المزايا في تبني ثقافة DevOps، ولكن ماهي هذه الثقافة؟ وما هي تجلياتها؟ احرص على قياس أداء فريقك ومساءلته وكن شفافًا إنه من المهمّ للغاية، في كل مرحلة، وضع مؤشرات أداء رئيسية واضحة (KPIs). يجب أن يعرف أعضاء الفريق دائمًا ما هو مُتوقّع منهم وكيف يلائم المشروع الكلي. لا تؤدي هذه الشفافية إلى تحسين التواصل فحسب، بل يمكن أن تفيد أيضًا في مساءلة الفريق. في الماضي، كانت العديد من الشركات تميل إلى عزل العمّال عن الأهداف و التصورات العامّة. ولا تتمّ مشاركة عناصر المشروع إلا على أساس "الحاجة إلى المعرفة". لكن فرق DevOps المميزة تخطت هذا المفهوم بشكل كامل. يجب أن يعلم الجميع كيف تعمل الأنظمة وكيف تتوافق الأشياء معًا. توفر أدوات التعاون مثل Microsoft Azure DevOps Server وبدائل أخرى ذات مصادر مفتوحة للفرق صورة واضحة لمراحل المشروع خلال التخطيط والتطوير والاختبار والنشر. ينبغي أن تتأكد من أن كل عضو في الفريق يفهم الهدف المشترك. كلما زاد فهم أعضاء الفريق لدورهم ومدى ملاءمته للآخرين، زادت كفاءة أدائهم. أنت بهذا تريد أعضاء الفريق أن يعملوا بنوع من المراقبة المتبادلة عبر المجموعات الوظيفية. أتمِت ما تستطيع يتمثل جزء كبير من ثقافة DevOps في التشغيل التلقائي قدر الإمكان وتوحيد منصات الإنتاج. يساعد التقييس والأتمتة في جعل عمليات النشر أكثر قابلية للتنبؤ بها وأقل عرضة للأخطاء البشرية. اعمل على أتمتة أي شيء يمكنك كجزء من سيرورة العمل، بما في ذلك البنية التحتية القابلة للتطوير والالتزام ومسلسل التسليم المستمر. على سبيل المثال، تسمح أدوات مثل Docker لفرق التطوير بأتمتة عمليات نشر التطبيقات بسرعة ملحوظة. من خلال تقليل المهام اليدوية والمتكررة، ستزيد من تطوّرك وسرعة اختبارك مع تقليل الأخطاء بشكل ملموس. بالإضافة إلى ذلك، من خلال التخلص من المهام الشاقة والمتكررة، ستحرّر أيضًا فريقك ليستطيع العمل على مهام رفيعة المستوى وتقلّل من التعب والإرهاق لديه. اخلق ثقافة التعاون يمكن أن يكون اعتماد ثقافة DevOps فرصة لكسر الجدران بين المستوى الإداري ووحدات العمل تمامًا. في بعض الأحيان يكون لفريق التطوير وفريق العمليات أولويات مختلفة، وهذا جيد، لكن يجب أن تعمل الشركات على إنشاء جسر تواصل بينهما. في ثقافات تكنولوجيا المعلومات الأخرى، يُقسّم تطوير البرامج لتحقيق السرعة عن طريق عزل أعضاء الفريق إلى أجزاء من المشاريع. يركز فريق التطوير على البرامج الجديدة والمبتكرة، بينما يعمل فريق العمليات على تخفيف المخاطر والحفاظ على النظام. لكن يمكن أن تخلق هذه الأولويات بعض الصدامات. تعمل ثقافة DevOps على مدّ الجسور بين هذه الأولويات عبر التواصل المبكر والمستمر. من خلال الجمع بين الفرق من بداية تطوير البرنامج، يمكنهم تحديد المخاطر والأخطاء والأعطاب قبل إرسال البرنامج إلى فرق العمليات. لن تنتظر الفرق حتى النهاية لتجتمع معًا ثم تُحدّد المشكلات التي كان يمكن حلها في وقت مبكر من دورة التطوير. تعني هذه المقاربة التشاركية أنه يمكن تطوير البرنامج بشكل أسرع مع وجود نسبة أقل من الأخطاء. بالإضافة إلى التحول الثقافي، ستحتاج الفرق إلى أدوات تطوير DevOps جديدة، مثل سجلات JFrog و Go ، والتي تتيح التقسيم والتعاون. إذ توفّر أدوات مثل هذه رؤية أوضح فضلا عن التواصل بين أعضاء الفريق. يخلق وجود مهام العمليات والتطوير عند نفس الفريق التعاون بين أفراده. بالإضافة إلى تعزيز الشعور الإيجابي بالفريق وأهميته، يمكن لثقافة DevOps أيضًا مساعدة أعضاء الفريق على تنمية مهاراتهم على المستوى الفردي أو إظهار مواهب أخرى. من خلال الجمع بين التطوير والعمليات، يكون قادة الفريق قادرين على تحديد طريقة تفكير الناس خارج مجال خبرتهم المحددة. يمكن أن يساعد تحدي أعضاء الفريق في التفكير فيما وراء أهدافهم ومعالجة المشكلات بشكل تعاوني الأفراد على إضافة مهارات أو رؤى إضافية إلى العملية الإجمالية. وقد يساعد هذا القادة في العثور على أعضاء الفريق اليوم الذين يستطيعون أن يصبحوا قادة فرق الغد. ضع أهدافاً واقعية وشفافة لا يوجد شيء أكثر إحباطًا لفرق DevOps من الأهداف غير الواقعية. إذا شعروا أن ما يطلب منهم القيام به أمر مستحيل، فمن المحتمل ألا يقدموا لك قصارى جهدهم. ومن خلال زيادة التواصل والرؤية بين الفرق، سيتمكن المديرون من وضع أهداف واقعية يمكن تحقيقها بشكل معقول. علاوة على ذلك، يفهم أفراد DevOps أيضًا بالعمل معًا جنبًا إلى جنب أداء الفريق بأكمله. عندها يكونون قادرين على معرفة أين تتأخر المشروعات أو ما إذا كانت تتقدم بشكل صحيح في إطار المسلسل برمّته. إن التخلي عن فكرة الفرق المنفصلة يمكّن الأفراد من التدخل والمساعدة عندما تكون أي لبنة رئيسية في خطر. من خلال رؤية العملية بكاملها، يكون حماسهم والتزامهم بالمشروع أكبر وتكون قدرتهم على إحداث تغيير إيجابي عند الحاجة وضمان تسليم المزيد من المشاريع في الوقت المحدد أعلى. هيّئ بيئة مشتركة للتعلّم والتحسين المستمر تتّسم أفضل فرق DevOps بالمرونة وتبحث باستمرار عن طرق للتحسّن. ويتجلى جزء مهمّ من التحسين المستمر في تكوين حلقات رسمية وغير رسمية للتواصل. يكتسي هذا الأخذ والعطاء أهمية بالغة بين الفرق والفروع المتخصّصة. فبالتواصل المنتظم بين وحدات الإنتاج والتطوير والتصميم والإدارة، يمكنك تقليل الوقت اللازم للتطوير. كما أن هذا يُمكّن كلّ فرد في فريق DevOps من التعرف على دوره في المنتج الإجمالي. يحب الناس أن يكونوا جزءًا من الفرق الناجحة التي تحقّق أهدافها وتتجاوزها باستمرار. إن النجاح يولد النجاح. وفي الوقت نفسه، من الأرجح أن يغادر أعضاء الفريق الذين لا يشعرون بالتحدي في عملهم أو الحصول على تقدير لمساهمتهم. لثقافة DevOps مزايا متنوعة ختامًا، تعدّ الفرق السريعة والمرنة والمبتكرة حيوية لنجاح الأعمال، ويمكن لثقافة DevOps أن تساعد في دفعها قُدماً نحو الأمام. فهي توفر تواصلًا أقوى، وترسم أهدافًا موحدة وشفافة، وتضع جداول زمنية واقعية. من خلال تشجيع الأتمتة وتوحيد العمليات، تُتيح DevOps أيضًا إنتاج برامج أسرع بأخطاء أقلّ. كما أنها تساهم في إيجاد أعضاء فريق سعداء ومتمكّنين يستطيعون المساهمة بأساليب جديدة. ربّما يكون اعتماد ثقافة DevOps هو الميزة التنافسية التي تحتاج إليها مؤسستك. ترجمة -وبتصرف- للمقال Why every dev team should adopt a DevOps culture in 2019 لصاحبه Matt Shealy
  7. تعرف على devopssec

    إن مفهوم DevSecOps كممارسة أو كشكل من أشكال الفن هو تطوير لمفهوم DevOps. لكي تفهم DevSecOps بشكل أفضل، ينبغي أولاً أن يكون لديك فهم كافٍ لما تعنيه DevOps، لذا ننصحك بالاطلاع على مقالات هذه السلسلة إن لم يكن لديك معرفة بماهية DevOps. وُلِدت ثقافة DevOps من دمج ممارسات التطوير (Development) والعمليات (Operations) وفك العزلة بينهما وتوحيد التركيز وتحسين الكفاءة والأداء لكلا الفريقين وللمنتج كذلك. لقد تشكّل مفهوم جديد للتعاون مع تركيز DevOps على صنع منتجات وخدمات تسهُل صيانتها وتعمل على أتمتة الوظائف العملية. إنّ الأمن حصن رئيسيّ مشترك لدى العديد من المؤسّسات. ويركّز المفهوم الأمنيّ على حماية المؤسسة، وهذا يعني أحيانًا إنشاء حواجز أو سياسات تبطئ من تنفيذ خدمات أو منتجات جديدة لضمان فهم كل شيء جيدًا وتنفيذه بأمان وعدم ظهور أي خطر على المؤسسة هي في غنى عنه. بالنظر إلى الطابع الاستثنائي للحصن الأمنيّ وإلى الاحتكاكات التي يمكن أن يظهرها، يعمل أفراد التطوير والعمليات أحيانًا في التفافٍ على الحصن الأمنيّ متجنّبين إياه من أجل تحقيق أهدافهم. في بعض الشركات، يخلق الحصن اعتقادًا بأن الأمن هو مسؤولية كاملة لفريق الأمن وأن الأمر متروك له لمعرفة ما هي العيوب أو المشكلات الأمنية التي يمكن ظهورها كنتيجة للمنتج. جاء مفهوم DevSecOps ليعمل على دمج نظام الأمان داخل منظومة DevOps. من خلال تعزيز الأمن أو بناءه في الدور التطويري أو العملياتي، أو من خلال تضمين الدور الأمني في مهامّ الفريق الهندسي، يجد الأمان نفسه في المنتج بشكل طبيعي ومقصود. يتيح ذلك للشركات إصدار منتجات وتحديثات جديدة بسرعة أكبر وبثقةٍ تامةٍ أنّ الأمان مضمّن كفايةً في المنتج. كيف تنسجم البرامج المتينة مع DevSecOps؟ يعدّ إنشاء البرامج المتينة (rugged software) جانبًا من جوانب ثقافة DevOps أكثر من كونه ممارسة منفصلة، وهو يكمّل ويعزز ممارسة DevSecOps. إن المنتج المتين مثله مثل شيء تصلّب و قَوِيَ عودُهُ من خلال التجارب و الخبرات. من المهم أن نلاحظ أن البرامج المتينة ليست بالضرورة آمنة بنسبة 100 ٪ (على الرغم من أنها قد تكون كذلك في وقت ما). ومع ذلك، فقد صُمّمت للتعامل مع مُعظم ما يمكن أن تواجهه. تتمثل المبادئ الأساسية لنشاط البرامج المتينة في تعزيز المنافسة والتجريب والفشل المتحكم فيه والتعاون. كيف تبدأ في DevSecOps؟ يتضمن الانطلاق في منظومة DevSecOps نقل متطلبات الأمان والتنفيذ إلى أقرب مرحلة ممكنة في عملية التطوير. إنّه يخلق في نهاية المطاف تحولًا في الثقافة يصبح معه الأمن مسؤولية الجميع، وليس فقط فريق الأمن. ربّما تكون قد سمعت بعض الفرق تتحدث عن "التحرّك نحو اليسار" (shift left). إذا بسطت مسلسل التطوير في خط أفقي لتضمين المراحل الرئيسية لتطور المنتج، من المرحلة البدئية إلى التصميم والبناء والاختبار وحتى التشغيل، فإن هدف الدور الأمني هو الاندماج في أقرب مرحلة ممكنة من هذه السلسلة. يسمح ذلك بتقييم المخاطر بشكل أفضل وتلطيفها وتخفيفها بشكل طبيعي. يعمل مفهوم "التحرّك نحو اليسار" على نقل هذه المشاركة إلى أقصى اليسار في هذا الخطّ الأفقي. تبدأ هذه الرحلة بثلاثة عناصر أساسية: التفويض التمكين التعليم يعني التفويض، في رأيي، تخفيف السيطرة والسماح للفرق باتخاذ قرارات مستقلة دون خوف من الفشل أو الارتداد. لكن التحذير الوحيد هنا هو أن المعلومات في غاية الأهمية لاتخاذ قرارات مستنيرة. من أجل تحقيق التفويض، يعتبر دعم الاستثمار والتنفيذ والذي يمكن القيام به من خلال المبيعات الداخلية والعروض التقديمية ووضع مقاييس لتحديد عوائد هذا الاستثمار أمرًا ضروريًا لكسر الحواجز القديمة وفكّ العزلة بين الفرق. سيساعدك بالتأكيد دمج الأمان في مهام فرق التطوير والعمليات وزيادة التواصل والشفافية في بدء الرحلة إلى DevSecOps. يسمح هذا التكامل والتعبئة للفرق بالتركيز على نتيجة واحدة تتجلى في بناء منتج تتشارك فيه المسؤولية وتتعاون على تطويره وأمانه بطريقة فعالة وموثوقة. سيأخذك هذا بعيدا في الطريق نحو تحقيق التفويض. إنه يجعل المسؤولية عن المنتج مشتركة بين الفرق التي تعمل على إنشائه ويضمن إمكانية فصل أي جزء من المنتج والحفاظ على أمانه. يتجلى التمكين في وضع الأدوات والموارد المناسبة في أيدي الفرق. يتعلق الأمر بخلق ثقافة مشاركة المعرفة من خلال المنتديات والتجمعات غير الرسمية. من المرجّح أن يساهم إنشاء ثقافةٍ تركز على الأتمتة وعلى وجوب ترميز المهام المتكررة إلى تخفيف العبء التشغيلي وتعزيز الأمان. يتجاوز هذا السيناريو مجرد توفير المعرفة بل يتعلق الأمر بإتاحة الوصول إلى هذه المعرفة بشكل كبير من خلال قنوات ووسائل متعددة توفرها العديد من الأدوات بما يتيح استخدامها ومشاركتها بأي طريقة تفضلها الفرق أو الأفراد. قد تعمل إحدى الوسائط بشكل أفضل في مرحلة كتابة الشيفرة بينما يكون غيرها مناسبًا في مراحل أخرى. اجعل الأدوات بسيطة وسهلة الوصول ودع الفريق يستخدمها بفعالية. سيكون لفرق DevSecOp المختلفة تفضيلات مختلفة، لذلك اسمح لهم بالاستقلال كلما أمكن ذلك. يعدّ هذا تمرينًا دقيقًا للتوازن لأنك تريد في الوقت ذاته وفرة في الإنتاج وقدرة على مشاركة المنتجات. سيساعد التعاون والمشاركة في اختيار وتجديد هذه الأدوات على تقليل الحواجز بين الفرق. أخيرًا، يدور مفهوم DevSecOps حول التدريب وبناء الوعي، و هذا ربّما هو الأمر الأهمّ في كل ما قلناه. تعد الاجتماعات واللقاءات الاجتماعية و العروض التقديمية الرسمية داخل المؤسسة طرقًا رائعة للأفراد لتلقين ومشاركة ما تعلّموه. في بعض الأحيان تبرز هذه التحديات أو المخاوف أو المخاطر المشتركة التي قد لا يلاحظها الآخرون. إن المشاركة والتدريب وسيلتان فعالتان للتعلّم ولإرشاد الفرق. وفقًا لتجربتي، تظلّ ثقافة كل مؤسسة فريدة من نوعها، لذلك لا يمكنك اتباع النهج القائل "مقاس واحد يناسب الجميع". تواصل مع فرقك واكتشف الأدوات التي يريدون استخدامها. اختبر مختلف المنتديات والتجمعات واعرف ما هو أفضل لثقافتك. ابحث عن التعليقات واسأل الفرق عمّا ينجح وعمّا يعجبهم ولماذا. تكيّف وتعلّم وكن إيجابيًا ولا تتوقف أبدًا عن المحاولة، وعلى الأغلب سوف يحالفك النجاح دائمًا. ترجمة وبتصرف للمقال ?What is DevSecOps لبريت هونولدت و آرون رينهارت