في وقت كتابة هذا التقرير ، أدى البحث في موقع عمل مشهور عن عبارة "Network Engineer" إلى وجود حوالي ثلاثمائة وظيفة شاغرة في جميع أنحاء روسيا. للمقارنة ، يُرجع البحث عن عبارة "مسؤول النظام" ما يقرب من 2.5 ألف وظيفة شاغرة ، و "مهندس DevOps" - ما يقرب من 800.
هل هذا يعني أنه لم تعد هناك حاجة إلى المسوقين الشبكيين في أيام السحب الرابحة ، و docker ، و kubernetis ، وشبكة Wi-Fi العامة في كل مكان؟
دعونا نفهم ذلك (ق)
دعونا تعرف. اسمي أليكسي ، وأنا أعمل على الشبكة.
لقد كنت أقوم بعمل شبكات لأكثر من 10 سنوات وعملت مع أنظمة * nix مختلفة لأكثر من 15 عامًا (أتيحت لي الفرصة لاختيار كل من Linux و FreeBSD). لقد عملت في مشغلي الاتصالات ، والشركات الكبيرة ، التي تُعتبر "مؤسسات" ، وقد عملت مؤخرًا في مجال التكنولوجيا المالية "الشابة والجريئة" ، حيث ستجعلني أنا وزملائي غير ضروري. في يوم ما. ربما.
إخلاء المسؤولية: "في حياتنا ، ليس كل شيء ، دائمًا وفي كل مكان ، ولكن هناك شيء ما ، أحيانًا في الأماكن" (ج) مكسيم دوروفيف.
كل ما هو مكتوب أدناه يمكن ويجب اعتباره الرأي الشخصي للمؤلف ، ولا يدعي أنه الحقيقة المطلقة ، وحتى دراسة كاملة. كل الشخصيات خيالية ، كل الصدف عشوائية.
مرحبا بكم في عالمي.
أين يمكنك أن تجد المسوقين الشبكيين؟
1. مشغلو الاتصالات وشركات الخدمات والمتكاملون الآخرون. كل شيء بسيط: الشبكة بالنسبة لهم هي عمل تجاري. فهم إما يبيعون الاتصال (المشغلون) مباشرة أو يقدمون خدمات لإطلاق / صيانة شبكات عملائهم.
هناك الكثير من الخبرة هنا ، ولكن ليس هناك الكثير من المال (إلا إذا كنت مديرًا أو مدير مبيعات ناجحًا). ومع ذلك ، إذا كنت تحب الشبكات ، وكنت في بداية رحلتك ، فستكون مهنة دعم بعض المشغلين ليست كبيرة جدًا ، حتى الآن ، نقطة انطلاق مثالية (كل شيء مكتوب جدًا في الفيدرالية ، وهناك مساحة صغيرة للإبداع). حسنًا ، القصص حول حقيقة أنه من الممكن أن تتطور من مهندس في الخدمة في غضون بضع سنوات إلى مدير من المستوى C هي أيضًا حقيقية تمامًا ، على الرغم من ندرتها ، لأسباب واضحة. هناك دائما حاجة للموظفين ، لأنه لا يزال هناك دوران. هذا جيد وسيئ في نفس الوقت - هناك دائمًا وظائف شاغرة ، من ناحية أخرى - غالبًا ما يكون الأكثر نشاطًا / ذكاءً بسرعة كافية إما أن يتم ترقيتهم أو الذهاب إلى أماكن أخرى "أكثر دفئًا".
2- "المؤسسة" المشروطة. لا يهم ما إذا كان نشاطه الرئيسي مرتبطًا بتكنولوجيا المعلومات أم لا. الشيء الرئيسي هو أن لديها قسم تكنولوجيا المعلومات الخاص بها ، والذي يعمل على ضمان تشغيل الأنظمة الداخلية للشركة ، بما في ذلك الشبكات في المكاتب وقنوات الاتصال بالفروع ، إلخ. يمكن أن تكون وظائف مهندس الشبكة في هذه الشركات "بدوام جزئي" يؤديها مسؤول النظام (إذا كانت البنية التحتية للشبكة صغيرة ، أو كان متعاقدًا خارجيًا منخرطًا فيها) ، ومدير الشبكة ، إذا كان لا يزال موجودًا ، يمكنه الاعتناء بالهاتف و SAN في نفس الوقت (وليس nuacho). يدفعون بطرق مختلفة - يعتمد ذلك بشدة على هامش العمل وحجم الشركة والهيكل. لقد عملت مع كل من الشركات التي تم فيها "تحميل السيكو في براميل" بانتظام ، ومع الشركات التي تم فيها إنشاء الشبكة من البراز والعصي والشريط الكهربائي الأزرق ، ولم يتم تحديث الخوادم تقريبًا على الإطلاق (من الضروري أن نقول أن هناك لم تكن هناك احتياطيات أيضًا). هناك خبرة أقل بكثير هنا ، ومن شبه المؤكد أنها ستكون في مجال قفل البائع الصعب ، أو "كيف تصنع شيئًا من لا شيء". شخصيًا ، بدا الأمر مملًا للغاية هناك ، على الرغم من أن العديد من الأشخاص يحبونه - كل شيء محسوب تمامًا ويمكن التنبؤ به (إذا كنا نتحدث عن الشركات الكبيرة) ، "dorah-bajato" ، إلخ. يقول بعض البائعين الرئيسيين ، مرة واحدة على الأقل في السنة ، إنهم توصلوا إلى نظام مخادع ضخم آخر يقوم بأتمتة كل شيء الآن ويمكن رفع تردد التشغيل على جميع مسؤولي النظام وشبكات الاتصال ، مما يترك زوجين يضغطان على الأزرار في واجهة جميلة. الحقيقة هي أنه حتى لو تجاهلنا تكلفة الحل ، فلن ينتقل المسندون الشبكيون إلى أي مكان من هناك. نعم ، من الممكن أنه بدلاً من وحدة التحكم ، سيكون هناك مرة أخرى واجهة ويب (ولكن ليس قطعة محددة من الحديد ، ولكن نظام كبير يدير عشرات ومئات من قطع الحديد هذه) ، ولكن معرفة "كيف يعمل كل شيء في الداخل "ستظل هناك حاجة.
3. شركات المنتجات، التي يأتي ربحها من تطوير (وغالبًا ، تشغيل) بعض البرامج أو الأنظمة الأساسية - ذلك المنتج بالذات. عادة ما تكون صغيرة وذكية ، فهي لا تزال بعيدة عن نطاق المؤسسات والبيروقراطية. يوجد هنا نفس هؤلاء المطورين ، والمكعبين ، وعمال الرصيف ، والكلمات الرهيبة الأخرى بأعداد كبيرة والتي ستجعل بالتأكيد الشبكة ومهندسي الشبكات بدائية لا داعي لها.
كيف يختلف مدير الشبكة عن مسؤول النظام؟
في فهم الناس وليس من تكنولوجيا المعلومات - لا شيء. كلاهما ينظر إلى الشاشة السوداء ويكتب بعض التعويذات ، وأحيانًا يتسمان بهدوء.
في فهم المبرمجين - ربما مجال الموضوع. يدير مسؤول النظام الخوادم ، ويدير مسؤولو الشبكة المحولات وأجهزة التوجيه. أحيانًا يكون المشرف سيئًا ، وكل شيء يقع على عاتق الجميع. حسنًا ، في حالة وجود أي غريب ، يقع اللوم أيضًا على المسوقين الشبكيين. Just because fuck you، that's why. فقط لأنك تبا لك ، لهذا السبب.
في الواقع ، الاختلاف الرئيسي هو نهج العمل. ربما يكون من بين المسوقين الشبكيين أنصار النهج "إنه يعمل - لا تلمسه!". يمكنك عادةً القيام بشيء ما (داخل بائع واحد) بطريقة واحدة فقط ، التكوين الكامل للصندوق - ها هو ، في راحة يدك. تكلفة الخطأ مرتفعة ، وأحيانًا تكون عالية جدًا (على سبيل المثال ، عليك السفر عدة مئات من الكيلومترات لإعادة تشغيل جهاز التوجيه ، وفي هذا الوقت سيكون عدة آلاف من الأشخاص بدون اتصال - وهو وضع شائع جدًا لمشغل الاتصالات ).
في رأيي ، هذا هو السبب في أن مهندسي الشبكات ، من ناحية ، لديهم دوافع قوية للغاية لاستقرار الشبكة (والتغييرات هي العدو الرئيسي للاستقرار) ، وثانيًا ، فإن معرفتهم تتعمق أكثر مما هي في الاتساع (لا تحتاج لتكون قادرًا على تكوين العشرات من الشياطين المختلفة ، فأنت بحاجة إلى معرفة التقنيات وتنفيذها من شركة تصنيع معدات معينة). هذا هو السبب في أن مسؤول النظام ، الذي بحث عن كيفية تسجيل شبكة محلية ظاهرية على tsiska ، ليس مديرًا للشبكة بعد. ومن غير المحتمل أن يكون قادرًا على تقديم الدعم الفعال (وكذلك استكشاف الأخطاء وإصلاحها) لشبكة معقدة إلى حد ما.
ولكن لماذا تحتاج إلى مدير شبكة إذا كان لديك مضيف؟
للحصول على أموال إضافية (وإذا كنت عميلاً كبيرًا ومحبوبًا ، ربما مجانًا ، "كصديق") ، سيقوم مهندسو مركز البيانات بتهيئة مفاتيح التبديل الخاصة بك لتناسب احتياجاتك ، وربما يساعدون أيضًا في رفع واجهة BGP مع الموفرين (إذا كان لديك الشبكة الفرعية الخاصة بك من عناوين IP للإعلان عنها).
المشكلة الرئيسية هي أن مركز البيانات ليس قسم تكنولوجيا المعلومات الخاص بك ، بل هو شركة منفصلة هدفها تحقيق ربح. بما في ذلك على نفقتك كعميل. يوفر مركز البيانات حوامل ، ويزودهم بالكهرباء والبرودة ، كما يوفر بعض الاتصال "الافتراضي" بالإنترنت. بناءً على هذه البنية التحتية ، يمكن لمركز البيانات تحديد موقع المعدات الخاصة بك (الموقع المشترك) ، أو تأجير خادم (خادم مخصص) لك ، أو تقديم خدمة مُدارة (على سبيل المثال ، OpenStack أو K8s). لكن عمل مركز البيانات (عادة) ليس إدارة البنية التحتية للعملاء ، لأن هذه العملية كثيفة العمالة ، وسيئة الأوتوماتيكية (وفي مركز البيانات العادي ، كل شيء مؤتمت) ، والأسوأ من ذلك (كل عميل هو فرد) وعمومًا محفوف بالمطالبات ("أخبرني أن الخادم قد تم إعداده ، والآن تعطل ، هذا كله خطأك !!! 111"). لذلك ، إذا كان المضيف يساعدك في شيء ما ، فسيحاول أن يجعل الأمر بسيطًا و "مسكن" قدر الإمكان. لأنه من الصعب القيام به - غير مربح ، على الأقل من وجهة نظر تكاليف العمالة لمهندسي هذا المضيف ذاته (لكن المواقف مختلفة ، انظر إخلاء المسؤولية). هذا لا يعني بالضرورة أن المضيف سيفعل كل شيء بشكل سيء. لكنها ليست حقيقة على الإطلاق أنه سيفعل بالضبط ما تحتاجه حقًا.
يبدو أن الأمر واضح تمامًا ، لكن في العديد من المرات في عملي ، صادفت حقيقة أن الشركات بدأت في الاعتماد على مزود الاستضافة أكثر بقليل مما ينبغي ، وهذا لم يؤد إلى أي شيء جيد. لقد استغرق الأمر وقتًا طويلاً لشرح بالتفصيل أنه لا توجد اتفاقية مستوى خدمة (SLA) ستغطي خسائر وقت التعطل (هناك استثناءات ، ولكنها عادةً ما تكون باهظة الثمن للغاية بالنسبة للعميل) وأن المضيف ليس على دراية على الإطلاق بما يحدث في البنية التحتية للعملاء (باستثناء المؤشرات العامة جدا). والمستضيف لا يقوم بعمل نسخ احتياطية لك أيضًا. الوضع أسوأ إذا كان لديك أكثر من مضيف واحد. في حالة وجود أي مشاكل بينهما ، فمن المؤكد أنهم لن يكتشفوا لك الخطأ الذي حدث.
في الواقع ، الدوافع هنا هي نفسها تمامًا عند اختيار "فريق الإدارة الخاص مقابل الاستعانة بمصادر خارجية". إذا تم حساب المخاطر ، والجودة تناسب الأعمال التجارية - فلماذا لا تجربها. من ناحية أخرى ، تعد الشبكة واحدة من أكثر طبقات البنية التحتية الأساسية ، ولا يستحق الأمر منحها للأجانب إذا كنت تدعم بالفعل كل شيء آخر بنفسك.
متى تحتاج إلى المسوق الشبكي؟
علاوة على ذلك ، سوف نركز على شركات المنتجات الحديثة. مع المشغلين والمؤسسات ، كل شيء واضح أو ناقص - لم يتغير الكثير هناك في السنوات الأخيرة ، وكانت هناك حاجة لشبكات الاتصال هناك من قبل ، هناك حاجة إليها الآن. ولكن مع هؤلاء "الصغار والجريئين" ليست الأمور بهذه البساطة. غالبًا ما يضعون بنيتهم التحتية بالكامل في السحاب ، لذا فهم لا يحتاجون حتى إلى مشرفين ، باستثناء مديري تلك السحابة ، بالطبع. البنية التحتية ، من ناحية ، بسيطة للغاية في تصميمها ، ومن ناحية أخرى ، فهي مؤتمتة جيدًا (ansible / puppet ، terraform ، ci / cd ... حسنًا ، كما تعلم). ولكن حتى هنا توجد مواقف لا يمكنك الاستغناء فيها عن مهندس الشبكة.
مثال 1 ، كلاسيكي
لنفترض أن شركة ما تبدأ بخادم واحد بعنوان IP عام يقع في مركز البيانات. ثم هناك نوعان من الخوادم. ثم المزيد ... عاجلاً أم آجلاً ، هناك حاجة لشبكة خاصة بين الخوادم. نظرًا لأن حركة المرور "الخارجية" محدودة بالنطاق الترددي (لا يزيد عن 100 ميجابت في الثانية ، على سبيل المثال) وبمقدار التنزيل / التحميل شهريًا (لدى المضيفين المختلفين تعريفات مختلفة ، ولكن النطاق الترددي للعالم الخارجي ، كقاعدة عامة ، كثير أغلى من شبكة خاصة).
يضيف المضيف بطاقات شبكة إضافية إلى الخوادم ويدرجها في محولاتهم في شبكة محلية ظاهرية منفصلة. تظهر شبكة LAN "مسطحة" بين الخوادم. مريح!
يتزايد عدد الخوادم ، وتتزايد أيضًا حركة المرور في الشبكة الخاصة - النسخ الاحتياطية والتكرار وما إلى ذلك. يعرض المستضيف نقلك إلى مفاتيح منفصلة بحيث لا تتدخل مع العملاء الآخرين ، ولا يتدخلون معك. يضع المستضيف نوعًا من المفاتيح ويقوم بتكوينها بطريقة ما - على الأرجح ، تاركًا شبكة واحدة مسطحة بين جميع الخوادم الخاصة بك. كل شيء يعمل بشكل جيد ، ولكن عند نقطة معينة ، تبدأ المشاكل: التأخيرات بين المضيفين تتزايد بشكل دوري ، والسجلات تقسم بعدد كبير جدًا من حزم ARP في الثانية ، واغتصب البنتستر منطقتك المحلية بالكامل أثناء المراجعة ، وكسر خادمًا واحدًا فقط.
ماذا علي أن أفعل؟
قسّم الشبكة إلى شرائح - vlans. قم بإعداد العنوان الخاص بك في كل شبكة محلية ظاهرية ، وحدد بوابة تنقل حركة المرور بين الشبكات. على البوابة ، قم بتكوين قائمة التحكم بالوصول (ACL) لتقييد الوصول بين الأجزاء ، أو حتى ضع جدار حماية منفصل بجوارها.
مثال 1 ، تابع
الخوادم متصلة بالمنطقة المحلية بسلك واحد. تكون المفاتيح الموجودة في الرفوف مترابطة بطريقة ما ، ولكن في حالة وقوع حادث في أحد الرفوف ، تسقط ثلاثة مفاتيح أخرى مجاورة. المخططات موجودة ، ولكن هناك شكوك حول مدى ملاءمتها. لكل خادم عنوانه العام الخاص به ، والذي يصدره المضيف ويرتبط بالحامل. أولئك. عند نقل الخادم ، يجب تغيير العنوان.
ماذا علي أن أفعل؟
قم بتوصيل الخوادم باستخدام LAG (Link Aggregation Group) بسلكين للمفاتيح الموجودة في الحامل (يجب أيضًا أن تكون زائدة عن الحاجة). احتفظ بالوصلات بين الرفوف ، وأعد صنعها بـ "نجمة" (أو CLOS العصرية الآن) بحيث لا يؤثر فقدان أحد الرفوف على الرفوف الأخرى. حدد الرفوف "المركزية" حيث سيتم وضع جوهر الشبكة وحيث سيتم تضمين الرفوف الأخرى. في الوقت نفسه ، رتب العناوين العامة بالترتيب ، خذ من المستضيف (أو من RIR ، إن أمكن) شبكة فرعية ، والتي تعلنها أنت بنفسك (أو من خلال المضيف) للعالم.
هل يمكن لمسؤول نظام "عادي" ليس لديه معرفة عميقة بالشبكات القيام بكل هذا؟ غير متأكد. هل المضيف يفعل ذلك؟ ربما سيكون كذلك ، لكنك ستحتاج إلى TOR مفصل إلى حد ما ، والذي ستحتاج أيضًا إلى تجميعه بواسطة شخص ما. ثم تحقق من أن كل شيء يتم بشكل صحيح.
المثال 2: غائم
لنفترض أن لديك VPC في بعض السحابة العامة. للوصول من المكتب أو الجزء الداخلي من البنية التحتية إلى الشبكة المحلية داخل VPC ، تحتاج إلى إعداد اتصال عبر IPSec أو قناة مخصصة. من ناحية أخرى ، IPSec أرخص. لا حاجة لشراء أجهزة إضافية ، يمكنك إنشاء نفق بين الخادم الخاص بك بعنوان عام والسحابة. لكن - تأخيرات ، أداء محدود (لأن القناة بحاجة إلى تشفير) ، بالإضافة إلى اتصال غير مضمون (حيث يمر الوصول عبر الإنترنت العادي).
ماذا علي أن أفعل؟
ارفع الاتصال من خلال قناة مخصصة (على سبيل المثال ، تسميها AWS الاتصال المباشر). للقيام بذلك ، ابحث عن عامل شريك يقوم بتوصيلك ، وحدد نقطة الاتصال الأقرب إليك (أنت في المشغل والمشغل في السحابة) ، وأخيرًا ، قم بإعداد كل شيء. هل يمكن عمل كل هذا بدون مهندس شبكات؟ بالتأكيد نعم. لكن كيفية استكشاف الأخطاء وإصلاحها بدونها في حالة حدوث مشاكل لم تعد واضحة.
وقد تكون هناك أيضًا مشكلات تتعلق بالتوافر بين السحب (إذا كان لديك وسائط متعددة) أو مشكلات في التأخير بين المناطق المختلفة ، وما إلى ذلك. بالطبع ، يوجد الآن العديد من الأدوات التي تزيد من شفافية ما يحدث في السحابة (نفس Thousand Eyes) ، ولكن هذه كلها أدوات مهندس شبكات ، وليست بديلاً.
يمكنني رسم عشرات الأمثلة الأخرى من ممارستي ، لكنني أعتقد أنه من الواضح أنه في الفريق ، بدءًا من مستوى معين من تطوير البنية التحتية ، يجب أن يكون هناك شخص (أو أفضل ، أكثر من واحد) يعرف كيف تكون الشبكة يعمل ، يمكنه تكوين معدات الشبكة والتعامل مع المشكلات إذا ظهرت. صدقني ، سيكون لديه ما يفعله
ما الذي يجب أن يعرفه المسوق الشبكي؟
ليس من الضروري على الإطلاق (بل وحتى ضارًا في بعض الأحيان) لمهندس الشبكة أن يتعامل فقط مع الشبكة ولا شيء أكثر من ذلك. حتى إذا لم نفكر في الخيار مع البنية التحتية التي تعيش بشكل كامل تقريبًا في السحابة العامة (وأيًا كان ما قد يقوله المرء ، فقد أصبح أكثر شيوعًا) ، ونأخذ ، على سبيل المثال ، في أماكن العمل أو السحابات الخاصة ، حيث "المعرفة على مستوى CCNP" لن تغادر.
بالإضافة إلى الشبكات - على الرغم من وجود مجال لا نهاية له للدراسة ، حتى لو كنت تركز فقط على اتجاه واحد (شبكات المزود ، المؤسسات ، مراكز البيانات ، Wi-Fi ...)
بالطبع ، سيتذكر الكثير منكم الآن لغة Python وغيرها من "أتمتة الشبكة" ، لكن هذا شرط ضروري فقط ، ولكنه ليس كافيًا. لكي ينضم مهندس الشبكة إلى الفريق بنجاح ، يجب أن يكون قادرًا على التحدث باللغة نفسها مع كل من المطورين وزملائه المشرفين / المطورين. ماذا يعني ذلك؟
- أن تكون قادرًا ليس فقط على العمل في Linux كمستخدم ، ولكن أيضًا إدارته ، على الأقل على مستوى مسؤول النظام الأصغر: قم بتثبيت البرنامج الضروري ، وإعادة تشغيل الخدمة المنهارة ، وكتابة وحدة نظام بسيطة.
- افهم (على الأقل بشكل عام) كيفية عمل مكدس الشبكة في Linux ، وكيف تعمل الشبكة في برامج Hypervisor والحاويات (lxc / docker / kubernetes).
- بالطبع ، أن تكون قادرًا على العمل مع نظام SCM / طاهٍ / دمية أو نظام SCM آخر.
- يجب كتابة سطر منفصل حول SDN وشبكات السحب الخاصة (على سبيل المثال ، TungstenFabric أو OpenvSwitch). هذا هو جزء آخر ضخم من المعرفة.
باختصار ، لقد وصفت متخصصًا نموذجيًا في شكل حرف T (كما أصبح من المألوف الآن أن نقول). يبدو أنه ليس شيئًا جديدًا ، ومع ذلك ، وفقًا لتجربة المقابلات ، لا يمكن لجميع مهندسي الشبكات التباهي بمعرفة موضوعين على الأقل من القائمة أعلاه. من الناحية العملية ، فإن الافتقار إلى المعرفة "في المجالات ذات الصلة" يجعل من الصعب للغاية ليس فقط التواصل مع الزملاء ، ولكن أيضًا لفهم المتطلبات التي تفرضها الشركة على الشبكة باعتبارها البنية التحتية ذات المستوى الأدنى للمشروع. وبدون هذا الفهم ، يصبح من الصعب الدفاع بشكل معقول عن وجهة نظرك و "بيعها" للأعمال التجارية.
من ناحية أخرى ، فإن عادة "فهم كيفية عمل النظام" تمنح المسوقين الشبكيين ميزة جيدة جدًا على "العموميين" المختلفين الذين يعرفون عن التقنيات من المقالات الموجودة في محادثات Habré / المتوسطة والبرقية ، ولكن ليس لديهم أي فكرة على الإطلاق عن مبادئ هذا أو هذا البرنامج يعمل. ومعرفة بعض الانتظامات ، كما تعلم ، تستبدل بنجاح معرفة العديد من الحقائق.
الاستنتاجات ، أو ببساطة TL ؛ DR
- مسؤول الشبكة (مثل DBA أو مهندس VoIP) هو متخصص في ملف تعريف ضيق نوعًا ما (على عكس sysadmins / devops / SRE) ، لا تنشأ الحاجة إليه على الفور (وقد لا تنشأ لفترة طويلة ، في الواقع) . ولكن إذا حدث ذلك ، فمن غير المرجح أن يتم استبداله بالخبرة الخارجية (الاستعانة بمصادر خارجية أو المسؤولين العامين العاديين ، "الذين يعتنون أيضًا بالشبكة"). ما هو محزن إلى حد ما هو أن الحاجة إلى مثل هؤلاء المتخصصين صغيرة ، وبشروط ، في شركة بها 800 مبرمج و 30 مطور / مشرف ، لا يمكن أن يكون هناك سوى اثنين من المسوقين الشبكيين الذين يقومون بعملهم على أكمل وجه. أولئك. كان السوق ولا يزال صغيرًا جدًا جدًا ، وحتى أقل براتب جيد.
- من ناحية أخرى ، يجب أن يعرف المسوق الشبكي الجيد في العالم الحديث ليس فقط الشبكات نفسها (وكيفية أتمتة تكوينها) ، ولكن أيضًا كيف تتفاعل أنظمة التشغيل والبرامج معها ، والتي تعمل عبر هذه الشبكات. بدون ذلك ، سيكون من الصعب للغاية فهم ما يطلبه الزملاء منك ونقل رغباتك / متطلباتك إليهم (بشكل معقول).
- لا توجد سحابة ، إنها مجرد كمبيوتر لشخص آخر. يجب أن تفهم أن استخدام السحابات العامة / الخاصة أو خدمات مزودي الاستضافة "الذين يفعلون كل شيء من أجلك" لا ينفي حقيقة أن تطبيقك لا يزال يستخدم الشبكة ، وستؤثر المشكلات المتعلقة بها على تشغيل تطبيقك . اختيارك هو مكان وجود مركز الاختصاص ، والذي سيكون مسؤولاً عن شبكة مشروعك.
المصدر: www.habr.com