Abdessamad El Omari

أنت تعمل على الانتقال إلى منظومة DevOps وتطبيقها في مؤسستك بالكامل أو في جزءٍ منها فقط: حسنًا! ها قد حقّق شخص ما في مكان ما قفزة نوعية. لنفترض، لأغراض هذا المقال، أن لديك موافقة من الإدارة: مهما كانت العقبات التي ينبغي عليك تجاوزها وكيفما كانت الجبال التي تحتاج لتسلقها للحصول على ذلك الجواب بـ "نعم". لقد حصلت على موافقة على الأدوات ووضعت كل الإجراءات والعمليات على الطاولة، والآن كل ما عليك القيام به هو إقناع الناس بالاندماج في المنظومة. يجب أن يكون هذا الأمر سهلا، أليس كذلك؟ نتمنى لو يكون كذلك. يتضح أنه ليس كل الناس مستنيرين مثلك أنت قارئ هذا المقال. لا يحب الناس كلّهم التغيير، وإذا كان هناك شيء واحد يمكنك التأكد منه، فهو هذا الأمرُ. ستحقق منظومة DevOps التغيير لمؤسستك: كيف عليك أن تعمل؟ وماذا تفعل؟ وكيف تتفاعل مع الأشخاص الآخرين داخل الفريق وخارجه؟ سوف أَصِفُ هنا خمسة أنواع من الأشخاص أو الأدوار الذين قد يعارضون عملية الانتقال إلى DevOps، كما سأعرض بعض الأفكار حول التكتيكات الممكنة للمساعدة في تحفيزهم للاندماج فيها. ومع ذلك، يجب أن نتذكر أنك قد لا تتمكن من تعبئة الجميع، وقد تكون هناك أسباب وجيهة لعدم رغبة الناس في تغيير ما يقومون به، بما في ذلك حقيقة أن ما يقومون به في الوقت الحالي قد يعمل بشكل جيد، سواء بالنسبة لهم أو للمنظمة. هذا لم يُخترَع من أجلنا: الخوف من المجهول "لقد فعلنا هذا على مدار الأعوام الماضية (سنة أو سنتان أو خمس أو عشر أو خمس وعشرون سنة)، وكان هذا الأمر ينجح دائمًا حتى اليوم". لقد سمعنا جميعًا عبارات كهذه. وقد يكون هذا صحيحًا أو قد لا يكون كذلك، ولكن إذا قررت إدارتك أنه يجب إجراء الانتقال إلى DevOps حتى لو كانت الممارسات الحالية تعمل، فمن الأرجح أن يكون هناك إدراك أن الأمور يمكن أن تكون أكثر كفاءةً أو سرعةً أو أمانًا. إن إحدى النقاط المُحدِّدَة لهذا النوع من الأشخاص أو الأدوار هي أنه يتصرف في كثير من الأحيان كفريق. وغالبًا ما تعتاد الفرق على طريقة معينة للقيام بالأشياء وعلى استقرار في الأدوار والروتينات التي تناسبها. وبالتالي فما تقترحه أنت هنا يمثل إزعاجًا للفريق ويجعل الناس يفعلون أشياء مختلفة. يجب أن تفكر في كيفية تحقيق أقصى استفادة من الفريق كما هو موجود الآن، أو ربما بنقل أعضاء ذلك الفريق معًا أو بإبداء نوع من الاحتفال بنجاحهم، بدلاً من اقتراح التغيير و تعليله بأنهم فشلوا بطريقة أو بأخرى. مجالي: الخوف من فقدان السيطرة هذا نوع من الأشخاص أعرفه تمامًا على المستوى الشخصي بحكم خلفيتي الأمنية. غالبًا ما يشعر الأشخاص الذين حصلوا على مستوى عالٍ من الخبرة في ميدان أو مجال معين بالتهديد عندما يُطلب منهم تغيير طريقة عملِهم أو تطبيقِ معارفهم. سيشعرون غالبًا بأنهم مطالبون بالتخلي عن السيطرة و بـ "تخفيف" خبراتهم في عالم جديد فيه "كلّ شخص هو الخبير". ما يهمّ التأكيد عليه في هذا السياق هو أنه بدلاً من تخفيف خبراتهم، تعدّ هذه فرصة لتطبيقها على مجموعة واسعة من العمليات. ينبغي على خبراء الاختبار أن يشرحوا للمطورين وأفراد العمليات، على سبيل المثال، كيف يمكن عرض منهجيات الاختبار في مجالاتهم. عادةً ما ينظر الخبراء بإيجابيةٍ إلى مسألة عرضهم أمام جمهور أوسع، وعلى الرغم من أنه سيكون هناك دائمًا شخصيات من نوع "البرج العاجي" تكافح من أجل التفاعل في إطار أكثر جماعية، فإن استخدام هؤلاء بطرق يأخذون فيها دور "الاستشاري" قد يوفر فرصًا إيجابيةً. متشبث بأسلوبي: الخوف من الجديد رغم أنه يشبه إلى حد بعيد شخصية "لم يخترع من أجلنا"، إلا أنه يعد فردًا أكثر من كونه سمة جماعية. قد تبدو معرفة ما ستكون عليه مهامك على أساس يومي تافهة للبعض ولكنها قد تكون مريحةً للغاية بالنسبة للكثيرين، وهذا هو السبب في أنهم قد لا يرغبون في الانتقال إلى عالم يبدو "أكثر حرية" وغير منظّمٍ. لا يمكن أن يكون الجميع مثل ذلك النوع من الموسوعيين الذين ينجحون في فهم جميع الأجزاء المختلفة من دورة DevOps. الخبر السار هنا هو أنك ستظل بحاجة إلى أشخاص مستعدين للاستقرار في مهام محددة وإكمالها بطرق معينة. في الواقع، على الرغم من وجود مخاوف مبدئية حول الانتقال إلى بيئة مختلفة للعمل، فإن توضيحك لأعضاء الفريق أنه سيكون لديهم قدر لا بأس به من التحكم في كيفية أدائهم لمهام معينة قد يكون رسالةً إيجابيةً عند محاولة مساعدة هذا النوع من الأفراد. ونأمل أن يساهم تضمينك للتدريب، رسميًا كان أو غير رسمي، كجزء من تحولك إلى DevOps وكذا الفرص المتاحة لتعلم مهارات جديدة (وبالتالي زيادة حركية الأفراد وفرص العمل) أيضًا كحوافز للتغيير. مدراء الأفراد: الخوف من فقدان السلطة يتمتع المديرون في العديد من المؤسسات، وخاصة تلك التي تتمتع بتسلسل هرمي قويٍّ ومتطوّرٍ، بقدر كبير من التحكم في كيفية انتشار موظفيهم وطبيعة مهامهم وكيفية إدارة تقدمهم الوظيفي. كل هذه الأمور يمكن أن تكون مباشِرة خلافًا لمقاربة DevOps التي تعدّ أكثر انفتاحًا. بالنسبة للمديرين الذين بنوا إمبراطوريتهم الصغيرة بالتحكم في تقاريرهم الرئيسية و الفرعية مثل البيادق حول لوحة الشطرنج، سيكون الانتقال إلى DevOps تحدّيًا كبيرًا. أما بالنسبة للمديرين الذين يحرصون على تطوير أعضاء فرقهم ليصبحوا موظفين أكثر خبرة، والذين يقيسون نجاحهم بعدد الفرق الأخرى التي تطلب إعارة تقاريرها إلى فرقهم، والذين يستمتعون كذلك برؤية مهارات جديدة وبالتقدم الوظيفي، ستكون DevOps بالتأكيد فرصةً مثيرةً. من الراجح أن يكون أسلوب العصا و الجزرة جزءًا من أي حلٍّ لمشكلة المديرين الذين يقاومون الإدارة التنفيذية. يمكن أن تتضمن الجزرة تغيير كيفية مكافأة المديرين وفقًا لآلية تتبنى هذه السلوكيات الجديدة، في حين قد تتضمن العصا تجريد فرقهم من بعض أعضائها أو إعادة تحديد دور هؤلاء المديرين. النقابات: الخوف من عدم اليقين في بعض المصانع والمناطق، هناك نقابات قوية. تتمثل المهمة الأساسية للنقابات في حماية العمال من الاستغلال من قبل الإدارة التي قد تحاول فرض تغييرات على العمال لن تعود عليهم بفائدة. تشتبه النقابات بشكل افتراضي ومفهومٍ كذلك في أي تغييرات تدخلها الإدارة، لذا فإن أي انتقال إلى DevOps تباركه الإدارة قد يثير مخاوف ومقاومة النقابات وأعضائها. في بعض الحالات، قد يكون الموظفون قد وصفوا بعناية أدوارهم الوظيفية التي تجعل من الصعب تقديم طرقٍ للعمل يتوقع منهم فيها القيام بدور أكثر موسوعيةً وتعلم مهارات جديدة، وهذان كلاهما من خصائص DevOps. والخبر السار هنا هو أن DevOps يمكن أن توفر المزيد من التحكم لأعضاء الفريق، بطرق مختلفة كثيرة، مما يقلل إلى حد ما من السيطرة التي تمارسها وظيفة الإدارة. سيكون توضيح ذلك والتأكد من إجراء عمليات الفحص المناسبة لحماية الوظائف أحد المفاتيح الرئيسية لإقناع النقابات وأعضائها بأن هذا تغيير جيد بالنسبة لهم. والشيء الآخر الذي كان يجب أن يحدث، بالطبع، هو أنه كان ينبغي على الإدارة إدماجهم مبكرًا في العملية للتأكد من انخراطهم من البداية، بدلاً من اتخاذ قرارٍ "نبت" فجأة في اللحظة الأخيرة. أفكار ختامية مع تقدمنا نحو مستقبل جديد مشرق، تجدر الإشارة إلى أن الخير العام للجميع لا يترجم دائمًا إلى تغيير إيجابي لكل فرد. يصعب القول أن بناء شبكات الصرف الصحي ليس خيرًا عامًّا، لكنه يؤذي من كانت وظيفتهم الحرص على نظافة الشوارع. نأمل ألا ترى انتقالك إلى DevOps كإنشاء مجموعة جديدة من شبكات الصرف الصحي لمؤسستك، ولكن انتبه إلى أولئك الذين قد يكون التغيير بالنسبة لهم صعبًا ومضطربًا. يمكن أن يكون هناك تكلفة بشرية لأي تطوير مهما حسنت نيته. بالنسبة لي، أهم نقطة ينبغي تذكرها هي أنه عندما يصبح الأشخاص دفاعيين، بل وأحيانًا عدوانيين، يكون ذلك عمومًا لأنهم يشعرون بالتهديد، وفي كل هذه الحالات التي فحصناها، قد يكون التغيير مهدِّدًا بالفعل. إن هؤلاء الناس هم زملاؤك. وهُم أناس أيضًا، ويجب معاملتهم باحترام وتقدير كأشخاص، وليس فقط كأدوار أو عقبات يتعين التغلب عليها. في بعض الحالات، قد يكون الحفاظ على الوضع الراهن في أجزاء خاصة من مؤسستك الخيار الأكثر أمانًا، في الوقت الحالي على الأقل. ترجمة وبتصرف للمقال Who will push back the most on a move to DevOps?‎ لمايك بورسيل

عندما تُنشئ خادم أوبونتو 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

لا يدرك معظم الناس1 تمامًا مقدار المتعة التي في الأمان، أو بالضبط كيف تجعلك الخبرة الأمنية مثيرًا بالنسبة للأشخاص الآخرين2. نحن نعلم أنها شيقة وجذابة وممتعة، لكنهم لا يعلمون ذلك. لهذا السبب، عندما يتوجه مسؤولو الأمن إلى الأشخاص الآخرين (دعنا نسميهم "أشخاصًا عاديين" لأغراض هذه المقالة)، ويقولون لهم إنهم يفعلون شيئًا خاطئًا، ولا يمكنهم إطلاق منتجهم، أو نشر طلباتهم، أو أنه يجب عليهم التوقف عن استلام طلبات المبيعات على الفور وربما خلال اليومين المقبلين حتى يتم إصلاح ذلك، عندها قد لا يتفاعل هؤلاء الأشخاص العاديون دائمًا بمستوى الامتنان الذي نعتقد أنّه مناسب. في بعض الأحيان، في الواقع، سيعرضون ردودًا سلبية، قد تكون حتى شخصية، على هذه الاقتراحات. تكمن المشكلة في أنّ أفراد الأمن يعرفون كيف ينبغي أن تكون الأمور، و هذا آمن. لقد تلقوا التدريب وحضروا الدورات وقرأوا المقالات وتصفحوا الكتب الأمنية الضخمة3، وكل هذه المصادر تؤكّد بوضوح تامٍّ: يجب أن يكون كل شيء آمنًا. تعني كلمة "آمن" عمومًا "مغلقًا"، خاصة إذا كان أفراد الأمن لم يشاركوا بشكل كاف في إجراءات التصميم والتنفيذ والعمليات. يريد الناس العاديون، من ناحية أخرى، فقط أن تعمل الأشياء. هناك انفصال جوهري بين وجهتي النظر هاتين لأننا لن نستطيع الإصلاح إلا إذا كان الأمن هو المطلب الأساسي لأي مشروع من بدايته وحتى نهايته4. ليس الأشخاص العاديون الآن أغبياء. إنهم يعلمون أن الأمور لا تعمل دائمًا بشكل مثالي؛ لكنهم يرغبون في عملها أكبر قدر ممكن. وهذه هي الفجوة التي نحتاج إلى تخطيها. لقد تحدثت من قبل عن التدهور المُتحكّم فيه كمفهوم، وهذا جزء من القصة. أحد الأشياء التي ينبغي لأفراد الأمن أن يكونوا مستعدين للقيام بها هو توضيح أن هناك مخاطر يمكن التخفيف منها. بالنسبة لأفراد الأمن، يجب التخفيف من هذه المخاطر من خلال "الإغلاق". إنّه من السهل إيقاف الخطر إذ يمكنك فقط إيقاف تشغيل النظام، ولن يوجد خطر من إساءة استخدامه. ولكن بالنسبة للعديد من الأشخاص، هناك مخاطر أخرى: مثال على ذلك أن المؤسسة قد تتوقف في الواقع عن العمل تمامًا لأن بعض أفراد الأمن قد أغلقوا نظام الطلبات. إذا كانوا قد عرضوا عليّ خيار الموازنة بين مخاطرة التوقف عن تلقي الطلبات مقابل مخاطرة فقدان بعض بيانات الشركة الداخلية، فهل كنت سأقوم بالمخاطرة الأولى؟ حسنا نعم، قد أقدم عليها. ولكن إذا لم يُقدّم لي الاختيار، ولم تُوضّح لي المخاطرة، فلن يكون لدي خيار. هذا هو نوع الكلمات التي أودّ سماعها إذا كنت أدير أعمالًا. ليس هذا فقط هو نوع المخاطر الممكنة. فأن تأتي مثلًا إلى اجتماعِ المشروع قبل أسبوعين من إطلاقه وتعلن أنه لا يمكن نشر المشروع "لأن المحادثات على واجهة برمجة التطبيقات هذه تتم دون تصديق على الهوية" ليس أمرًا جيّدًا على الإطلاق لأي أحد. باعتباري مطوّرًا، فلديّ على أيّة حال مفردات مختلفة وهواجس مختلفة عن تلك الخاصة بمالك العمل. ماذا لو أنه بدلًا من العبارة التالية: "تحتاج إلى استخدام التّصديق على الهوية على واجهة برمجة التطبيقات هذه وإلّا لن تستطيع المتابعة"، يطرح مسؤول الأمان السؤال كالتالي: "ماذا سيحدث إذا كانت البيانات التي تُقدّم على واجهة برمجة التطبيقات هذه غير صحيحة، أو يقدّمها شخص ينوي تعطيل عمل النظام؟" وفقًا لتجربتي ، يهتمّ معظم المطورين ويلتزمون بالتشغيل الصحيح للنظام الذي يعملون عليه والبيانات التي يعالجها. في الغالب، تثير الأسئلة التي تُظهر التأثير المحتمل لانعدام الأمن ردود فعل إيجابية أكثر من "مناقشة" بدائية تنتهي أساسًا بالرفض. لا تفهمني خطأً؛ إن هناك أوقاتًا نحتاج فيها، كأفراد أمن، لأن نكون حازمين ومتشبثين بأسلحتنا5. ولكن في النهاية، فإن مالكي الأنظمة أو المنظمات أو وحدات الأعمال أو الموارد هم الذين يتخذون القرار النهائي. إن مهمتنا هي التحدث إليهم بكلمات يمكنهم فهمها والتأكد من أنهم مطلعون جيدًا قدر الإمكان و نتفادى أن يكون جوابهم مجرد "لا". أعني بذلك "أولئك المساكين الذين لا يقرؤون هذه المنشورات، على عكسك، عزيزي القارئ الذكي". يبدو أن زوجتي، للأسف، تندرج في هذه الفئة. الكتب التي عادة ما يكون على غلافها صورة قفلٍ. ونتمنى لك التوفيق في ذلك. مجازًا فقط، فأنا لا أقبل نقل أي أسلحة إلى مكان العمل بما في ذلك الأسلحة النارية. ترجمة وبتصرف للمقال Talking to normal people about security لمايك بورسيل

في خضم السباق المحموم نحو الرقمنة، أصبحت فرق التطوير تمثّل العمود الفقري للعديد من المؤسّسات. لقد أصبح يتعين على أفرادها إلى جانب فرق العمليات القيام بمهمّات أكثر من أي وقت مضى. غالبًا ما تقود هذه الفرق الابتكار والتغيير في نفس الوقت الذي تحافظ فيه على النظام القديم وتضمن أداء المنتجات أو الخدمات باستمرار. إن المؤسّسات التي تسمح لفرق التطوير والعمليات لديها بالمرونة والسرعة في التحرك واستثمار الفرص تكون في الغالب مؤسّسات ناجحة، وهذا ما يجعل العديد من المنظمات تعطي الأولوية لبناء وتعزيز ثقافة 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

إن مفهوم 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 لبريت هونولدت و آرون رينهارت