هل هناك حياة بعد Windows أو أين يجب أن يتطور مسؤول / مهندس نظام Windows في عام 2020؟

دخول

2019 يقترب ببطء ولكن بثبات من نهايته. تستمر صناعة تكنولوجيا المعلومات في التطور بنشاط ، مما يسعدنا بعدد كبير من التقنيات الجديدة وعلى طول الطريق تجديد مفرداتنا بتعريفات جديدة: البيانات الضخمة ، الذكاء الاصطناعي ، التعلم الآلي (ML) ، إنترنت الأشياء ، 5G ، إلخ. هذا العام ، موثوقية الموقع تمت مناقشة الهندسة بشكل خاص في كثير من الأحيان (SRE) ، DevOps ، الخدمات المصغرة والحوسبة السحابية.

يبدو أن بعض التقنيات ، مثل Blockchain والعملات المشفرة (Bitcoin و Ethereum وما إلى ذلك) ، قد تجاوزت بالفعل ذروة شعبيتها (الضجيج) ، لذلك تمكن عامة الناس من إلقاء نظرة أكثر رصانة عليها ، وتحديد إيجابياتهم. والجوانب السلبية ، بالإضافة إلى تحديد مكان وكيفية استخدامها بشكل أفضل. يمكن العثور على نظرة متوازنة على موضوع Blockchain والعملات المشفرة في مقال بقلم أليكسي مالانوف من شركة كاسبرسكي لاب. أنا أوصي التدقيق بها.

تكتسب التقنيات الأخرى شعبيتها فقط حتى الآن ، وتشكل مجتمعات نشطة من حولها ، بما في ذلك ليس فقط المؤيدين والمؤيدين ، ولكن أيضًا المعارضين المتحمسين.

هل يذهب الجميع إلى DevOps؟

إشارة خاصة مني اليوم ستذهب إلى DevOps ، وهو نهج جديد لتطوير البرامج وتشغيلها. كان هناك بالفعل العديد من المقالات والنزاعات حول هذا الموضوع هذا العام.

هل هناك حياة بعد Windows أو أين يجب أن يتطور مسؤول / مهندس نظام Windows في عام 2020؟

يتم تفسير مصطلح DevOps اليوم على نطاق واسع. يفهم شخص ما تحت DevOps نهجًا خاصًا لتطوير البرامج وتشغيلها ، عندما يشارك في العمل الأشخاص القادرون على البرمجة قليلاً والمسؤول. بالنسبة للآخرين ، هذا ، أولاً وقبل كل شيء ، وجود مسؤول نظام شخصي في الفريق ، والذي يسمح لك بإزالة جزء من الحمل غير الأساسي من مطوري البرامج في شكل إعداد بيئة النظام ، وإنشاء بيئات اختبار ، تنفيذ التكامل مع الخدمات الداخلية والخارجية وكتابة نصوص الأتمتة. بالنسبة للآخرين ، إنها مجرد مجموعة من التقنيات والأدوات العصرية التي تحتاج إلى استخدامها لتبقى دائمًا شابًا وناجحًا. بالنسبة للرابع ، فهو CICD وكل ما يتعلق به. تمتلك DevOps بالفعل الكثير من التفسيرات ، بحيث يمكن لأي شخص أن يجد فيها بشكل مستقل ما هو أقرب إلى رغبته.

تؤدي التفسيرات المختلفة لـ DevOps إلى مناقشات ساخنة ، مما يؤدي إلى ظهور المزيد من المقالات حول هذا الموضوع. حتى أنني حفظت بعضها في إشاراتي المرجعية:

  1. من هم DevOps؟
  2. كيف تدخل إلى DevOps وكيف تتعلم وماذا تقرأ.
  3. لماذا يجب أن يصبح مسؤولو النظام مهندسي DevOps.

إذا قرأت ما يكفي من المقالات التي تشيد بـ DevOps ، فقد تحصل على انطباع بأن أي مسؤول / مهندس نظام يحتاج فقط إلى تغيير موقعه الحالي في ملف تعريف LinkedIN الخاص به من مسؤول مهندس DevOps ، وستبدأ الدعوات لإجراء مقابلات من الموارد البشرية من الشركات الكبيرة والناجحة على الفور صب في. ، الذي يعد براتب أعلى مرتين من الراتب الحالي ، سيقدم جهاز Macbook جديدًا ، وسكوتر جيروسكوبي ، ولن ينسى الاشتراك في عبوات vape المجانية وعدد لا حصر له من العصائر. بشكل عام ، سوف تأتي جنة تكنولوجيا المعلومات.

إذا قرأت مقالات تقلل من مزايا DevOps ، فسيبدأ انطباع آخر في التبلور بأن DevOps هو نوع جديد من العبودية ، حيث يتعين على الأشخاص البرمجة على نفس مستوى المطورين تقريبًا ، ومساعدتهم في إصلاح الأخطاء ، والقيام بالأتمتة و CICD ، انشر Jira من Wiki ، وقم بتدوير السحب ، وجمع الحاويات وإدارتها ، أثناء القيام بالأعمال الإدارية بالتوازي ، مع عدم نسيان إعادة تعبئة الخراطيش ، وكبس الأزواج الملتوية ، وسقي زهور المكتب.

ولكن ، كما تعلم ، فإن الحقيقة عادة ما تكون في مكان ما في الوسط ، لذلك سنحاول اليوم فهم القليل عن كل شيء.

لا مزيد من المدراء؟

بصفتي مسؤول / مهندس نظام يعمل مع منتجات Microsoft و VMware لبعض الوقت ، بدأت في ملاحظة أنه في السنوات القليلة الماضية كانت هناك محادثات بشكل دوري تفيد بأن لا أحد سيحتاج إلى مسؤولي النظام قريبًا ، للأسباب التالية:

  1. البنية التحتية بأكملها على وشك التغيير والتحول إلى IaaC (البنية التحتية كرمز). الآن لن يكون هناك واجهة مستخدم رسومية بأزرار ، ولكن فقط PowerShell وملفات yaml والتكوينات وما إلى ذلك. إذا تعطلت إحدى الخدمات أو مكوناتها ، فلم يعد من الضروري إصلاحها ، لأن من الأسرع نشر نسخة جديدة منه من آخر حالة عمل.
  2. ستنتقل البنية التحتية لتكنولوجيا المعلومات بالكامل قريبًا إلى السحابة ، وسيكون هناك محليًا (محليًا) فقط كبلات شبكة لأقرب جهاز توجيه يربطنا بجميع موارد الشركة الأخرى الموجودة في السحابة. حسنًا ، ستبقى الطابعة محليًا على الأكثر حتى تتمكن فتيات قسم المحاسبة من طباعة صور القطط من الإنترنت عليها. يجب أن يكون كل شيء آخر في السحابة.
  3. سيأتي معلمو DevOps ويقومون بأتمتة كل شيء حولهم ، لذلك لن يتذكر المسؤولون إلا بدفء في أرواحهم كيف قاموا في الأيام الخوالي بتشغيل الأصوات والتتبع لتشخيص المشكلات الأساسية على الشبكة وعلى الخوادم.
  4. سمعت أيضًا عن ظاهرة مثل "Vendekapets" ، لكنها كانت منذ وقت طويل جدًا ، في فجر مسيرتي المهنية ، عندما كنت قد بدأت للتو في اتخاذ خطواتي الأولى نحو إدارة النظام. ولكن لسبب ما ، لم يأتِ "Vendekapets" أبدًا ، مثل نهاية العالم وفقًا لتقويم المايا. صدفة؟ لا تفكر. 🙂

هل من الممكن أن مديري نظام Windows ، الذين يعملون عن كثب مع منتجات Microsoft اليوم ، لن يفيدوا أي شخص قريبًا؟ أم لا تزال هناك حاجة لهم؟ هل سيستمر مسؤولو Windows في ارتداء وضعهم كمهندسين إداريين ، أم سيتم نقلهم إلى دور قوة عاملة منخفضة المهارات على غرار أي مفتاح (أعط ، أعط ، جلب)؟

حتى هنا على habr.com في مركز إدارة النظام ، لا نرى سوى إشارات إلى kubernetes و linux و devops و docker و open source و zabbix. أين هي الكلمات المحببة إلى قلوبنا Windows أو Active Directory أو Exchange أو System Center أو Terminal أو خوادم الطباعة أو خوادم الملفات أو البرامج النصية bat و vbs أو على الأقل بوويرشيل. اين كل هذا؟

هل هناك حياة بعد Windows أو أين يجب أن يتطور مسؤول / مهندس نظام Windows في عام 2020؟

فهل هناك حياة بعد أن يتعين على مسؤولي نظام Windows أو Windows إنهاء كل شيء الآن لتعلم Linux و docker و kubernetes و ansible و python والانتقال إلى DevOps؟

ربما يكون كل شيء على ما يرام مع Windows ، فقط الآن هناك ضجة مؤقتة لحزمة Linux + docker + kubernetes + ansible + python ، والتي طغت على Windows المحبوب لدينا؟ ما الذي يتعين على مسؤول نظام Windows القيام به في عام 2020 ليكون مطلوبًا في سوق العمل؟

للأسف ، هناك أسئلة أكثر من الإجابات هنا ، لذا ستحاول المقالة الحالية مساعدتنا في ترتيب الأمور قليلاً. المقالة مخصصة بشكل أساسي لمسؤولي ومهندسي Windows ، لكنني متأكد من أنها ستكون ذات فائدة لمتخصصي تكنولوجيا المعلومات الآخرين أيضًا.

مايكروسوفت تذهب إلى الغيوم؟

يعد مسؤول Windows ، أولاً وقبل كل شيء ، مناصرًا لمايكروسوفت ، لذلك سنتحدث عنها وعن منتجاتها الرائعة.

تمتلك Microsoft مجموعة واسعة من الحلول البرمجية ، والعديد منها رواد في مجالاتهم. إذا كنت تعمل كمسؤول Windows كمهندس ، فمن المرجح أنك صادفتهم بطريقة أو بأخرى. سأقدم أدناه وصفًا موجزًا ​​لكل منتج وأصف الاحتمالات المحتملة لتطويرها خلال 3-5 سنوات القادمة. هذا ليس سرا من الداخل من المقر الرئيسي في ريدموند ، ولكن رأيي الشخصي ، لذا فإن وجهات النظر البديلة في التعليقات مرحب بها بكل الطرق الممكنة.

هل هناك حياة بعد Windows أو أين يجب أن يتطور مسؤول / مهندس نظام Windows في عام 2020؟

المنشآت المحلية (في أماكن العمل)

مايكروسوفت تبادل خادم هو خادم بريد متعدد الوظائف لا يتضمن فقط العمل مع البريد ، ولكن أيضًا مع جهات الاتصال والتقويمات والمهام وغير ذلك الكثير. يعد Exchange Server أحد المنتجات الرئيسية لشركة Microsoft ، والذي أصبح المعيار الفعلي للشركات في العديد من الشركات. لديها تكامل وثيق ليس فقط مع منتجات Microsoft نفسها ، ولكن أيضًا مع الحلول من البائعين الخارجيين. التبادل شائع في كل من الشركات المتوسطة (من 100 شخص) والشركات الكبيرة.

في هذا الوقت ، يعتبر Exchange Server 2019 هو الإصدار الحالي.في السابق ، تم تطوير المنتج بنشاط كبير ، ولكن بدءًا من إصدار Exchange 2013 ، تباطأ هذا التطور كثيرًا ، لذلك يمكن تسمية Exchange 2016 بشكل مشروط Service Pack 1 (SP1) لـ Exchange 2013 ، و Exchange 2019 - ومن ثم Service Pack 2 (SP2) لـ Exchange 2013. لا يزال مصير الإصدار المحلي التالي (Exchange 2022) محل شك.

تعمل Microsoft الآن بنشاط على الترويج لـ Exchange Online كجزء من خدمة Office 365 السحابية ، لذلك تظهر جميع الميزات الجديدة هناك أولاً وقبل كل شيء. إن Exchange Online ليس فقط أول من يحصل على ميزات جديدة ، ولكنه يكتسب أيضًا ميزات إضافية لن يتم نقلها إلى عمليات التثبيت المحلية (داخل الشركة) في المستقبل القريب. يتم ذلك من أجل تسريع انتقال عدد من الشركات إلى السحاب ، لأن. يعتبر نموذج الاشتراك أكثر فائدة لشركة Microsoft من الناحية المالية من البيع لمرة واحدة.

إذا كنت تقوم حاليًا بصيانة تثبيت محلي لـ Exchange Server (2013 - 2019) ، فيمكنك الاستمرار في القيام بذلك لمدة 3-5 سنوات القادمة. على طول الطريق ، من المفيد البدء في استكشاف الإمكانيات التي يوفرها Exchange Online ؛ والتكوينات المختلطة ، وذلك عندما تكون الإصدارات المحلية والسحابة موجودة في نفس الوقت. حتى إذا افترضنا أن الإصدار التالي المحلي من Exchange لم يعد موجودًا ، فستظل المعرفة المكتسبة الآن على Exchange Server ذات صلة لبعض الوقت في المستقبل لعدد من الأسباب:

  • عدد عمليات التثبيت المحلية كبير جدًا حاليًا ، لذا ستكون هناك حاجة لمسؤولين مؤهلين لدعمها. لن تتمكن جميع المؤسسات من نقل بريدها إلى السحابة في المستقبل القريب لسبب أو لآخر.
  • لم تعد مشاريع الترحيل إلى السحابة تافهة حتى الآن ، لذا فإن المعرفة بخصائص كل من الحلول المحلية والحلول السحابية مطلوبة لتجاوز معظم المخاطر وإكمال الترحيل بنجاح.
  • تعد معرفة smtpimapmapipop3 وتدفق البريد و dkim و dmark و spf ومكافحة الفيروسات وبروتوكولات مكافحة البريد العشوائي عالمية وستكون قابلة للتطبيق على أي أنظمة بريد.
  • ستؤدي الخبرة المكتسبة أثناء العمل مع خادم Exchange المحلي إلى جعل فهم Exchange Online وإعداد التكوين المطلوب أسرع بكثير.
  • يعد البريد الإلكتروني من أهم قنوات الاتصال بالعالم الخارجي ، لذلك ستبقى الحاجة إليه. لا يمكن الاستماع إلى Adepts "السعاة وبرامج الدردشة ستحل محل البريد" ، لأن. لقد "دفنوا" البريد مرات عديدة وحتى الآن دون جدوى.

Skype for Business (SfB) (Lync سابقًا) هو برنامج مراسلة للشركات مع ميزات متقدمة. لديه تكامل وثيق مع خادم Exchange ، ولكنه أدنى بكثير من الأخير من حيث الشعبية. عادةً ما يتم استخدام Skype for Business فقط في الشركات الكبيرة ، لأن. إنه ليس ممتعًا جدًا للشركات الصغيرة والمتوسطة الحجم.

الإصدار الحالي هو Skype for Business 2019 ، والذي يحتوي على اختلافات طفيفة مقارنة بالإصدار السابق من Skype for Business 2016 ، لذلك يمكن اعتبار SfB 2019 مشروطًا Service Pack 1 لـ SfB 2016 ، وليس إصدارًا كاملاً جديدًا.

في سحابة Office 365 ، تم تمثيل هذا المنتج بواسطة خدمة Skype for Business Online ، والتي تم استبدالها بالكامل بعد مرور بعض الوقت بـ Microsoft Teams ، أي لا يتوفر Skype for Business حاليًا في Office 365 السحابي. لهذا السبب ، لا يستحق الأمر توقع الإصدار المحلي التالي من Skype for Business 2022 ، نظرًا لأن الأولوية بالنسبة لشركة Microsoft هي تطوير وتطوير برنامج Teams messenger ، والذي أصبح استجابة البائع لظهور برنامج Slack messenger الناجح.

إذا كنت تدير حاليًا Skype for Business محليًا وكنت تحب مفهوم برنامج مراسلة الشركات ، فأنا أنصحك بالنظر إلى Teams كجزء من Office 365 ، وإلا فمن الأفضل اختيار منتج آخر لترقية معرفتك ، لأن. النسيان ينتظر Skype for Business المحلي. على عكس Exchange ، الذي أصبح المعيار الفعلي في مكانة خادم البريد ، لدى Skype for Business اليوم بدائل. Team و Slack للشركات الكبيرة والمتوسطة. Telegram و Viber و Whatsapp - للشركات الصغيرة.

شير - بوابة داخلية للشركات حيث يمكن للشركات نشر خدمات الويب المفيدة الخاصة بها (جدول الإجازات ، قائمة الموظفين بالصور وأرقام الهواتف ، تذكيرات أعياد الميلاد ، أخبار الشركة ، إلخ). يمكن للمستخدمين تخزين الملفات التي يستضيفونها في مكتبات SharePoint الخاصة بهم وتحريرها ومشاركتها.

إن SharePoint مثل Bitrix24 ، فهو أكبر فقط وأكثر فاعلية وأكثر تكلفة وأكثر صعوبة في الإعداد والصيانة. الميزة القاتلة هي القدرة على تحرير مستند واحد في وقت واحد من قبل عدد كبير من الموظفين ، وهو أمر مريح للغاية عندما يحاول 100 شخص ملء جدول الإجازة ، والتكامل مع Office Online Server و MS Office المحلي.

Sharepoint هو منتج كبير ومعقد ومكلف ، لذلك عادةً ما تستخدمه الشركات الكبيرة فقط. تستخدم الشركات الصغيرة Bitrix24 أو نظائرها ، أو تقوم ببساطة بتخزين الملفات على خوادم الملفات ، وتوزيع خدمات الويب المفيدة على مواقع داخلية مختلفة.

عادةً ما تتم إدارة مزارع SharePoint (المجموعات) بواسطة المطورين بوظائف المسؤول ، وليس بواسطة مسؤولي النظام "البحتين" ، لأن لكي ينطلق SharePoint ويكون مفيدًا للشركة ، يجب أن يتم الانتهاء منه بالكثير من التعليمات البرمجية.

يتضمن Office 365 خدمة SharePoint Online ، وهي نسخة مبسطة من SharePoint المحلي ، على سبيل المثال. لديه حد أدنى من إمكانيات التخصيص و "شربه لنفسه" ، لكنه يزيل الكثير من المتاعب من مدير المطور فيما يتعلق بتشغيله. رأيي هو أن التعقيد والتكلفة العالية لصيانة الإصدارات المحلية من SharePoint ستؤدي وظيفتها وستبدأ الشركات بسعادة في الزحف تدريجياً إلى SharePoint Online ، أو التخلي عن Sharepoint تمامًا لصالح حل أبسط. أنا شخصياً لا أرى حياة مشرقة وخالية من الهم لـ SharePoint في التركيبات المحلية.

مركز النظام هي مجموعة كاملة من المنتجات لنشر البنى التحتية الكبيرة لنظام Windows وتكوينها وإدارتها ومراقبتها. تشمل التحكيم: مدير تكوين مركز النظام (SCCM) ، مدير الجهاز الظاهري لمركز النظام (SCVMM) ، مدير عمليات مركز النظام (SCOM) ، مدير حماية بيانات مركز النظام (SCDPM) ، مدير خدمة مركز النظام (SCSM) ، منسق مركز النظام (SCORCH) ).

هل هناك حياة بعد Windows أو أين يجب أن يتطور مسؤول / مهندس نظام Windows في عام 2020؟

عادةً ما تكون المجموعة الكاملة من منتجات System Center مطلوبة فقط في الشركات الكبيرة ، بينما تستخدم الشركات المتوسطة الحجم عادةً منتجًا واحدًا أو منتجين فقط.

نظرًا لصعوبة تعلم منتجات System Center وعادة ما يتم استخدامها فقط في البنى التحتية الكبيرة ، فمن المعتاد تخصيص أفراد للعمل معهم ، على سبيل المثال ، مسؤول أنظمة المراقبة (SCOM) ، ومسؤول صيانة محطة العمل (SCCM) ، و مسؤول أنظمة المحاكاة الافتراضية (Hyper -V + SCVMM) ، مسؤول أتمتة البنية التحتية (SCORCH + SCSM).

تعمل Microsoft على تطوير خدماتها السحابية بسرعة ، لذلك تنتقل وظائف System Center تدريجياً إلى السحابة. كل هذا سيكون له تأثير قوي على منتجات System Center المحلية في المستقبل القريب جدًا.

وظيفي منظم مركز النظام (SCORCH) ستحل محل خدمة Azure Automation في المستقبل (https://docs.microsoft.com/en-us/azure/automation/automation-intro).

وظيفي مدير عمليات مركز النظام (SCOM) سيحل محل خدمة Azure Monitor في المستقبل (https://docs.microsoft.com/en-us/azure/azure-monitor/overview).

وظيفي مدير حماية بيانات مركز النظام (SCDPM) سيحل محل خدمة Azure Backup في المستقبل (https://docs.microsoft.com/en-us/azure/backup/backup-overview).

وظيفي مدير خدمة مركز النظام (SCSM) لن تكون مطلوبة أو سيتم استبدالها بأي نظام تذاكر آخر ، على سبيل المثال ، Jira.

مدير الجهاز الظاهري لمركز النظام (SCVMM) لا يزال مع الشركات التي تشغل Hyper-V الافتراضية في أماكن العمل في الوقت الحالي. يمكن إدارة عمليات تثبيت Hyper-V الصغيرة (10-15 خادمًا) بنجاح تام بدون SCVMM باستخدام الأدوات القياسية فقط - مدير مجموعة تجاوز الفشل ، مدير Hyper-V ، مركز إدارة Windows.

مدير تكوين مركز النظام (SCCM) - تُستخدم للنشر الشامل لأنظمة التشغيل ، وتثبيت تطبيقات الشركات من دليل واحد ، وتثبيت تحديثات Windows على الخوادم ومحطات العمل النهائية ، وجرد التطبيقات ، وحساب التراخيص. يبدو أن هذا هو المنتج الوحيد من خط System Center بأكمله الذي سيبقى معنا في البنية التحتية المحلية ، لأنه. لا يمكن استبداله بالكامل بشيء غائم في الوقت الحالي.

إذا كنت تدعم حاليًا تثبيتًا محليًا لـ System Center Configuration Manager (SCCM) ، فيمكنك متابعة القيام بذلك. سيكون المنتج معنا لمدة 3-5 سنوات قادمة على الأقل. بالإضافة إلى ذلك ، أوصي بالبدء في استكشاف إمكانيات Office 365 لأن. هذا سوف يسير على ما يرام مع منصب Enterprise Desktop Administrator.

سيتم إنهاء دور المسؤول لمعظم منتجات System Center الأخرى كـ تعمل خدمات Azure على تبسيط عملها بشكل كبير ، وإخفاء كل التعقيدات عن أعين المتطفلين. لنأخذ مسؤول التشغيل الآلي (SCORCH + SCSM) كمثال. سيتم استبدال SCORCH بـ Azure Automation. ستبقى المعرفة بعملية الأتمتة ، PowerShell ، SQL وستكون مفيدة لأتمتة Azure ، لكن المعرفة حول بناء مجموعات SCORCH ، وضمان توفرها العالي ، وحجم الموارد ، والتحديث ، والترحيل إلى الإصدارات الجديدة ، والنسخ الاحتياطي والمراقبة ستفقد أهميتها ، لأن . ستتولى سحابة Azure كل هذا العمل. سيركز مسؤول الأتمتة فقط على عملية الأتمتة نفسها ، مثل كل الأعمال اللازمة للحفاظ على كفاءة البنية التحتية للأتمتة ستختفي عنه.

خادم ويندوز وأدواره

الدليل النشط (AD) - مكان يتم فيه تخزين حسابات المستخدمين والكمبيوتر. إذا كان لدى الشركة أكثر من 20 جهاز كمبيوتر ، فمن المرجح أن يكون هناك بالفعل نوع من مجال Active Directory هناك. معرفة Active Directory ، والقدرة على تمييز المجال من الغابة ، ومهارة العمل مع سياسات المجموعة إلزامية لأي مسؤول Windows. ستكون هذه المعرفة ذات صلة لمدة 20 عامًا أخرى.بالإضافة إلى ذلك ، أوصي بأن تتعرف على Azure AD (AAD) ، وأن تنظر في خيارات مزامنة المستخدمين بين البنية التحتية في مكان العمل والبنية التحتية السحابية.

DNS ، DHCP - خدمات الشبكة ، التي يفيد فهمها في جميع مجالات تقنية المعلومات ، من الإدارة إلى البرمجة ، لذا فأنت بحاجة إلى معرفتها. سيكون فهم عمل الشبكات وبروتوكولات التوجيه ونماذج OSI و TCPIP ميزة إضافية محددة لأي متخصص في تكنولوجيا المعلومات.

فرط-V - اسم المجموعة الكاملة لتقنيات المحاكاة الافتراضية من Microsoft وبرنامج Hypervisor الخاص بها على وجه الخصوص. إنه يتطور بسرعة كبيرة ، على الرغم من أنه في رأيي ، فإن معظم الميزات الجديدة (Shielded VM ، والشبكات الفرعية المشفرة ، ومساحات التخزين المباشرة) تركز بشكل أساسي على موفري الخدمات السحابية المحليين (موفري الخدمات السحابية) والعالمية (Azure) ، وليس على الشركات الجزء (المؤسسة). هذا مفهوم بشكل عام ، نظرًا لأن Microsoft تقوم أولاً بتنفيذ واختبار وظائف جديدة في سحابة Azure الخاصة بها ، وبعد ذلك فقط تنقلها إلى Windows Server و Hyper-V.

لا يزال Hyper-V يعاني من عدم وجود وحدة تحكم واحدة مجانية توفر جميع الميزات الضرورية. الآن لدينا Failover Cluster Manager ، Hyper-V Manager ، مركز إدارة Windows. كان من المفترض أن تكون وحدة التحكم هذه من نوع SCVMM ، لكنها مدفوعة ومن الصعب إلى حد ما إتقانها.

إذا كنت تدعم حاليًا تثبيتًا محليًا لـ Hyper-V بدون SCVMM ، فيمكنك الاستمرار في القيام بذلك. بالتوازي مع ذلك ، أوصي بالبدء في دراسة Azure IaaS وآليات ترحيل الأجهزة الافتراضية بين السحابة والبنية التحتية المحلية.

من بين بيئتي (البنوك وشركات الاتصالات وشركات التأمين والمقتنيات الصناعية الكبيرة) ، عادةً ما تتم إدارة جميع المحاكاة الافتراضية الإنتاجية بواسطة VMware vSphere ، وليس Hyper-V مع SCVMM ، لذلك يمكنني أن أوصي مسؤول Hyper-V بالبحث أيضًا عن VMware و المنتجات.

خدمات سحابية

مكتب 365 هي خدمة سحابية توفر حزمة اشتراك لتطبيقات Microsoft Office (المحلية وإصدارات الويب الخاصة بها) ، وتتضمن أيضًا منتجات الخادم الرئيسية - Exchange و Teams و OneDrive و Sharepoint.

في الوقت الحالي ، يعد Office 365 خدمة مكتفية ذاتيًا تغطي احتياجات اتصالات المكتب بالكامل تقريبًا. نظرًا لسهولة الإعداد ، فهو رائع لكل من الشركات الصغيرة والشركات المتوسطة والكبيرة.

إن التواجد في السحابة لخدمات Exchange و Teams و OneDrive و Sharepoint التي تم نشرها بالفعل يقلل بشكل كبير من العبء على مسؤول النظام ، لأنه جميع إجراءات التثبيت وتحديد حجم الموارد والتحديث والترحيل إلى الإصدارات الجديدة تقع الآن بالكامل على عاتق Microsoft. في حين أنه كان مطلوبًا في السابق 4-6 مسؤولين مخصصين لدعم Exchange و Teams و OneDrive و Sharepoint في البنية التحتية المحلية ، أصبح الآن مسؤول واحد فقط كافيًا في Office 365. إذا كان هناك شيء لا يعمل أو لا يعمل بشكل صحيح ، فيمكنك إنشاء تذكرة للدعم الفني من Microsoft مباشرةً من واجهة Office 1 ، وهو أمر مريح للغاية.

إذا كنت الآن مسؤول نظام تحتفظ بإصدارات محلية من Exchange أو Skype for Business أو منتجات Sharepoint ، فأنا أوصي بالنظر إلى إصداراتها السحابية كجزء من Office 365 لفهم كيف تناسبك والوظائف التي تقدمها مقارنةً بـ -إصدارات.

Azure هي عبارة عن منصة سحابية عالمية من Microsoft تتضمن مجموعة دائمة التوسع من الخدمات السحابية لمساعدة المؤسسات على مواجهة تحديات أعمالها. في الوقت الحالي ، يتضمن Azure أكثر من 300 خدمة مجمعة في فئات مختلفة (الحوسبة ، والشبكات ، والتخزين ، وقواعد البيانات ، والتحليلات ، وإنترنت الأشياء ، والأمان ، وتطوير العمليات ، والحاويات ، وما إلى ذلك).

بعد ظهوره لأول مرة في عام 2009 ، يحتل Microsoft Azure الآن أحد المراكز الرائدة في سوق الخدمات السحابية العالمية ، حيث يتنافس بنجاح مع Amazon AWS هناك.

حسب آخر تقرير مالي (https://www.microsoft.com/en-us/Investor/earnings/FY-2019-Q4/press-release-webcast) نمت أرباح Microsoft ربع السنوية (الربع الرابع 4) بنسبة 2019٪ بسبب نجاح Office 49 والأعمال السحابية. نمت الإيرادات من Azure بنسبة 365٪.

تعد Azure ، جنبًا إلى جنب مع Office 365 ، المجالات الرئيسية التي توجه فيها Microsoft مواردها المالية والتنظيمية.

يمكن لوفرة الخدمات على النظام الأساسي Azure أن تربك حتى أخصائي تكنولوجيا المعلومات ذوي الخبرة ، لذلك سيكون أدناه وصفًا للبنية التحتية لبرغي الخادم النموذجية ، حيث سأشير بين قوسين إلى نظائرها التقريبية في سحابة Azure. آمل أن يكون هذا بمثابة نقطة بداية للتعرف على Azure ، لأنه ، كما تعلم ، يجب أن تبدأ صغيرًا ، وتتحرك تدريجياً بشكل أعمق.

تبدو بنية Windows الأساسية النموذجية من جانب الخادم كما يلي:

  • Active Directory (AD) مع سياسات المجموعة ونظام أسماء النطاقات. (Azure Active Directory (AAD) ، Azure DNS).
  • DHCP
  • تبادل خادم البريد. (Exchange عبر الإنترنت كجزء من Office 365).
  • مزرعة RDS مع خوادم طرفية متعددة. (جهاز ظاهري Azure + شبكة افتراضية Azure + تخزين Azure).
  • خادم ملفات حيث يقوم الموظفون بتخزين ملفاتهم. (تخزين ملفات Azure ، جهاز ظاهري Azure + شبكة افتراضية Azure + تخزين Azure)
  • الخوادم مع التطبيقات وقواعد البيانات (1C ، بوابة موقع الويب الداخلية ، CRM ، إلخ). (قاعدة بيانات Azure SQL ومواقع Azure على الويب و Microsoft Dynamics 365 والجهاز الظاهري Azure + شبكة Azure الافتراضية + تخزين Azure)

المهام الإدارية الرئيسية هي:

  • إنشاء النسخ الاحتياطية. (النسخ الاحتياطي أزور).
  • جمع وتحليل السجلات. (تحليلات Azure Log).
  • أتمتة المهام الروتينية. (أتمتة Azure).
  • مراقبة حالة الخدمات واستلام إخطارات الأعطال (شاشة Azure).

أود أن أنصح مسؤولي Windows الذين يحتفظون بالبنية التحتية المحلية بالبحث أولاً عن نظائر خدماتهم المفضلة في سحابة Azure للعمل معهم قليلاً ، وتحديد فائدتها للشركة ، وربما تنظيم خيارات مختلطة ، واختيار أفضل ما في العالمين.

تدريب

يتحول تركيز Microsoft في تطوير منتجاتها تدريجياً إلى الحلول السحابية ، لذلك عليك أن تبدأ في تعلمها الآن. أين يمكنني الحصول على مزيد من المعرفة حول Azure باللغة الروسية؟ لسوء الحظ ، لا يوجد الكثير من هذه الموارد.

تعرض Microsoft استخدام مدخل Microsoft Learn الخاص بها - https://docs.microsoft.com/ru-ru/learn/browse/. تمت ترجمة المواد النصية إلى اللغة الروسية ، بينما كان الفيديو باللغة الإنجليزية ، وإن كان بترجمة روسية.

كمواد جيدة وعالية الجودة لدراسة Azure ، أوصي بدورة أساسيات Azure Exam AZ-900 التي يقرأها إيغور شاستيتكو على قناته على YouTube (https://www.youtube.com/watch?v=_2-txkA3Daw&list=PLB5YmwQw0Jl-RinSNOOv2rqZ5FV_ihEd7). يوجد الآن 13 مقطع فيديو ، ولكن إذا كان هناك دعم نشط كافٍ من المجتمع (مثل ، اشتراك) ، فستظهر المواد بشكل أسرع ولن يكون استمرارها طويلاً في المستقبل.

بالإضافة إلى ذلك ، أنصحك على قناة iwalker2000 بمشاهدة قائمة التشغيل "مهنة تكنولوجيا المعلومات: كيف تصبح متخصصًا في تكنولوجيا المعلومات" ، والتي ستساعد المبتدئين على تحديد مسار تطورهم المهني وبناء مستقبل مهني بالطريقة الصحيحة. (https://www.youtube.com/watch?v=ojyHLPZA6uU&list=PLB5YmwQw0Jl-Qzsq56k1M50cE6KqO11PB)

لسوء الحظ ، لا يوجد العديد من المواد على Azure باللغة الروسية كما نرغب ، لذلك إذا كنت تعرف أي موارد مفيدة أخرى حول هذا الموضوع ، فيرجى مشاركتها في التعليقات. سيشكرك العديد من محترفي تكنولوجيا المعلومات على هذا.

النتائج

ما هي الاستنتاجات التي يمكن استخلاصها من كل ما سبق؟

  1. لا تزال الحياة في البنية التحتية لـ Microsoft موجودة ، ولن تذهب إلى أي مكان. تمتلك Microsoft مجموعة واسعة إلى حد ما من حلول البرامج ، والعديد منها رواد في مجالاتهم ، لذلك دائمًا ما يكون لدى مسؤول النظام والمهندس شيئًا ما ليتعلمه وينفذه ويشغّله ويطوره.
  2. تتغير الآن البنية الأساسية لـ Microsoft بشكل نشط ، وهذا يحدث مع التركيز على تطوير الخدمات السحابية - Azure و Office 365. سيتم إنشاء منتجات وتطبيقات Microsoft الجديدة في البداية للعمل في السحابة ، مرتبطة بنموذج اشتراك شهريًا المدفوعات. سيجد بعض هذه المنتجات فقط بعد ذلك تجسيدًا لها في الحلول داخل الشركة.
  3. ستتركنا بعض المنتجات الباهظة الثمن والتي يصعب صيانتها قريبًا ، فننتقل كليًا أو جزئيًا إلى Azure cloud أو Office 365. سيصبح المسؤولون الأفراد الذين يحتفظون باستمرار بمنتج واحد فقط (على سبيل المثال SCOM و SCSM وما إلى ذلك) قريبًا ألغيت.
  4. إذا كنت مسؤولاً / مهندسًا متمرسًا في النظام تعمل في نظام Microsoft البيئي ، فليس من الضروري ترك كل شيء والتشغيل في DevOps ، والذي يتم الحديث عنه الآن في كل زاوية. يمكنك الاستمرار في التطوير بشكل أكبر في اتجاهك عن طريق إضافة الكفاءات في خدمات Azure السحابية و Office 365.
  5. لكي تظل مطلوبًا كمتخصص في سوق العمل ، سيتعين عليك الدراسة والدراسة والدراسة مرة أخرى. أصبح مفهوم "التعليم مدى الحياة" لتكنولوجيا المعلومات أكثر صلة من أي وقت مضى ، خاصة الآن في أوقات التطوير النشط لتقنيات السحابة.
  6. DevOps الآن في ذروة شعبيتها (الضجيج). إنها حقيقة. في البداية ، كان يُنظر إلى DevOps على أنه منهجية تتيح لك الجمع بين تطوير البرامج والعمليات ، عندما يبدأ المبرمجون والمهندسون في العمل معًا لتحقيق هدف مشترك واحد - وهو تحسين البرامج. تم التركيز بشكل رئيسي على تغيير ثقافة الاتصال بين الفرق ، وتطوير آليات المساعدة المتبادلة والمسؤولية الجماعية عن النتيجة النهائية. ومع ذلك ، ونتيجة لذلك ، أدى ذلك إلى ظهور منصب جديد - مهندس DevOps ، الذي تم تفويضه بمهام مهندس الإصدار (CICD) ، ومسؤول التشغيل الآلي ، ومسؤول السحابة ومهندس العمليات. هذا بالفعل أمر واقع. عدد الوظائف الشاغرة لـ DevOps والمتطلبات الموجودة فيها تؤكد ذلك فقط.

    يمكن الآن اعتبار DevOps كمسار إضافي لتطوير مسؤول / مهندس النظام. تعد DevOps طريقة رائعة للمسؤول العادي لتغيير صناعته الحالية إلى صناعة تطوير البرمجيات. أولئك الذين يحبون الأتمتة وكتابة التعليمات البرمجية سيصبحون في النهاية مطورين ، وأولئك الذين يحبون أشياء البنية التحتية (الشبكات والخوادم ونظام التشغيل والسحاب وما إلى ذلك) سيصبحون مهندسي DevOps.

  7. إذا كنت مبتدئًا ، أو دخلت للتو في قسم تكنولوجيا المعلومات ، فإن DevOps هي الآن طريقة رائعة للترقية في فترة زمنية قصيرة والحصول على وظيفة في شركة عادية بأجر لائق ومكتب جيد ، لذلك تعلم Linux ، Ansible ، Docker ، Kubernetes و Python و CICD.

في الآونة الأخيرة ، زاد الطلب على نظام Linux الأساسي والحلول المتعلقة بتطوير البرامج ، ولكن هذا لا يحدث على حساب نظام Microsoft البيئي ، ولكن ببساطة ظهرت مكانة جديدة حيث يتم استخدام Docker و Kubernetes بنشاط ، ويتم قطع التطبيقات المتجانسة في الخدمات الصغيرة ، وتحتاج الأعمال إلى زيادة سرعة إصدارات البرامج لتقليل الوقت اللازم لتسويق الميزات الجديدة.

المصدر: www.habr.com

إضافة تعليق