استخدم هذا القالب
تحمي وثائق البنية التحتية الداخلية القوية شركتك من الأعطال وعمليات التدقيق وحوادث الأمن. باستخدام Trupeer، يمكنك توفير ساعات في وثائق البنية التحتية عبر البدء بقالب مجاني، وتخصيصه باستخدام إرشادات العلامة التجارية، وتحويل الوثائق إلى جولات فيديو لفِرق تقنية المعلومات وMSPs.
تُكتب معظم وثائق البنية التحتية مرة واحدة فقط، أثناء مشروع، ثم تصبح غير صحيحة خلال ستة أشهر. تبقى على الـ wiki، ولا يثق بها أحد، وخلال الحادث التالي يقرأها شخص ما، ويتردد، ثم يتصل بالشخص الذي يعرف الأمر فعليًا.
الحل ليس المزيد من الوثائق. بل تقليل الوثائق التي تُحافظ على صحتها، مع اختيارها عبر سؤال ما الذي يحتاجه شخص ما فعليًا عند الساعة الثالثة صباحًا.
حمّل قالب وثائق البنية التحتية
التنسيق | الأفضل لـ |
|---|---|
Excel (.xlsx) | جرد الأنظمة ومصفوفة الاعتماديات وتفاصيل الشبكة ومُتتبّع المراجعة |
Word (.docx) | Runbooks وخلاصة نظرة على المعمارية وخطة DR |
الإصدارات المعتمدة، وأي شيء يطلبه المدققون | |
Google Sheets | جرد مشترك يحافظ عليه الفريق |
Google Docs | Runbooks يتم تعديلها أثناء الحوادث وبعدها |
مجاني وقابل للتعديل وبدون علامة مائية. يقوم Excel بمعظم العمل هنا، لأن وثائق البنية التحتية هي في الغالب بيانات مُهيكلة تتظاهر بأنها نثر.
أي وثائق تحتاج؟
تحتاج إلى توثيق | استخدم |
|---|---|
ما البنية التحتية الموجودة وكيف تتصل | هذا القالب |
عمليات تقنية المعلومات والسياسات ودليل “كيف” بشكل عام | |
مشروع محدد | |
منتج برمجي لمستخدميه | |
إجراء في تقنية المعلومات | |
معمارية البرمجيات والتصميم |
كيفية تخصيص هذا القالب في Trupeer
الخطوة 1: افتح قسم القوالب
انتقل إلى قسم القوالب من التنقل الرئيسي.
الخطوة 2: اختر قالبًا وافتحه
انقر على أي قالب تريد العمل عليه لفتحه.
الخطوة 3: وسّع عرض القالب
إذا لزم الأمر، وسّع عرض القالب لرؤية التخطيط الكامل والتفاصيل بوضوح.
الخطوة 4: عدّل القالب
انقر على Edit لبدء تعديل القالب المحدد.
داخل المحرر، يمكنك:
إضافة أقسام جديدة
تحديد أو تحديث قواعد التنسيق
إضافة شعار وضبط موضعه والإعدادات ذات الصلة
الخطوة 5: احفظ قالبك المخصص
بعد إجراء جميع التغييرات اللازمة، انقر Save لتخزين القالب المحدّث كنسختك الخاصة.
الخطوة 6: المعاينة والضبط الدقيق للقالب
عندما تريد رؤية شكل القالب المخصص لديك، افتح Preview.
من شاشة المعاينة، يمكنك الاستمرار في إجراء تعديلات مباشرة عند الحاجة، لضمان ظهور القالب تمامًا كما تريد.
باستخدام قالب وثائق البنية التحتية الداخلية يمكنك:
توفير ساعات في الكتابة: تخطَّ الصفحة الفارغة مع بنية مُعدة لبنية تقنية المعلومات التحتية.
تحسين وضع الأمن: حقول مدمجة تفرض ممارسات آمنة للتعامل مع بيانات الاعتماد.
الالتزام بالهوية: طبّق شعارك وخطوطك وألوانك باستخدام Trupeer's brand kit.
تقليل وقت التوقف: تقلل الوثائق الواضحة MTTR أثناء الحوادث.
الجاهزية للتدقيق: متوافق مع SOC 2 وISO 27001 وأطر مشابهة.
الوصول إلى فرق عالمية: ترجمة الوثائق إلى 65+ لغة بنقرة واحدة.
اختبار الساعة الثالثة صباحًا
الاختبار الوحيد الذي يهم وثائق البنية التحتية.
تخيّل حادثًا عند الساعة الثالثة صباحًا. الشخص الذي بنى النظام على متن طائرة. شخص كفؤ لكنه غير معتاد على وثائقك ينظر إليها. هل يمكنه معرفة ما الذي تعطل، وما الذي يعتمد عليه، وما الذي سيحدث إذا أعاد تشغيله، ومن يجب تصعيد الأمر إليه؟
كل ما يساعد في ذلك يستحق الكتابة. أما كل شيء آخر فهو اختياري، والوثائق الاختيارية هي ما يخفف الأجزاء المفيدة ويستهلك ميزانية الصيانة.
طبّقه بلا رحمة. تاريخ تفصيلي لسبب اختيار تقنية ما في 2021 لا ينجح. ملاحظة تقول إن هذه الخدمة يجب تشغيلها بعد قاعدة البيانات وقبل بوابة API.
ما الذي ينجح في اختبار الساعة الثالثة صباحًا
ما الموجود. الأنظمة والخوادم والخدمات، مع ما يفعله كل واحد منها في جملة واحدة.
أين يوجد. مزود السحابة والمنطقة، أو الموقع الفعلي والرف.
ما الذي يعتمد عليه، وما الذي يعتمد عليه. أغلى شيء في وثائق البنية التحتية.
كيف تصل إليه. أسماء المضيفين والعناوين ووحدات التحكم، لكن دون بيانات اعتماد.
كيف يبدو الوضع الطبيعي. حتى يتمكن شخص غير معتاد من معرفة ما إذا كان هناك خطأ فعليًا.
ما الذي يسبب تعطلها. أوضاع الأعطال المعروفة وأعراضها.
كيفية إعادة تشغيلها بأمان، بما في ذلك الترتيب وأي شيء يجب فعله أولًا.
من يملكها، ومسار التصعيد مع تفاصيل تواصل حقيقية.
ما نطاق التأثير. ما الذي سيتوقف إذا حدث ذلك.
ما الذي لا ينجح عادة
مكتوب من أجل الاكتمال بدل الاستخدام، وبالتالي لا يستحق الحفاظ عليه.
تفريغ إعدادات كامل يصبح قديمًا في اليوم التالي للتصدير. تبرير تفصيلي لقرارات سابقة، والذي ينتمي إلى سجل قرار المعمارية بدل الوثائق التشغيلية. كل معلمة لكل نظام عندما لا يهم تشغيلًا سوى عدد قليل منها. لقطات شاشة لوحدات التحكم التي تتقادم بسرعة ونادرًا ما تساعد. وأي شيء يكرر مصدر الحقيقة في مكان آخر، لأن نسختين تعني أن واحدة خاطئة ولا يمكنك معرفة أيهما.
المبدأ العام: إذا كان يمكن اكتشافه من النظام أسرع مما يمكن قراءته من وثيقة، فلا توثقه.
جرد البنية التحتية
الأساس. صف واحد لكل نظام أو خدمة.
الحقل | أدخل |
|---|---|
الاسم | كما يظهر في المراقبة وفي المحادثة |
الغرض | جملة واحدة بلغة بسيطة |
النوع | خادم، خدمة، قاعدة بيانات، جهاز شبكة، SaaS |
البيئة | الإنتاج، التجهيز، التطوير |
الموقع | مزود السحابة والمنطقة، أو الموقع والرف |
المالك | الفريق، وجهة تصعيد محددة بالاسم |
الأهمية | المستوى 1 إلى 3، محدد أدناه |
يعتمد على | ما يحتاجه ليعمل |
يعتمد عليه | ما الذي سيتعطل إذا توقف |
طريقة الوصول | وحدة التحكم، SSH bastion، VPN. ليست بيانات اعتماد |
المراقبة | أين تذهب تنبيهاتها |
النسخ الاحتياطي | التكرار، الموقع، آخر استعادة تم التحقق منها |
Runbook | رابط |
آخر تحقق | التاريخ الذي أكد فيه شخص ما أن هذا الصف صحيح |
آخر حقل هو الأكثر الذي تتجاهله معظم الجردات، وهو الذي يحدد ما إذا كان أي شخص يثق بالوثيقة. صف لم يتحقق منه أحد منذ سنتين يجب أن يبدو غير موثوق بشكل واضح بدل أن يكون خاطئًا بصمت.
مستويات الأهمية
حددها، لأنها تحدد مقدار الوثائق التي يستحقها كل نظام.
المستوى | يعني | الوثائق المتوقعة |
|---|---|---|
1 | تعطل يوقف العمل | Runbook كامل، DR مُختبر، خريطة الاعتماديات، مراجعة ربع سنوية |
2 | تعطل يضعف وظيفة | Runbook، الاعتماديات، مراجعة مرتين سنويًا |
3 | تعطل يمكن تحمله ليوم | إدخال جرد ومالك فقط |
توثق معظم المؤسسات المستوى 3 بنفس عمق المستوى 1، ثم تنفد طاقتها، وتنتهي مع كل شيء موثقًا بشكل نصف. نفّذ المستوى 1 بشكل صحيح واترك المستوى 3 صفًا واحدًا.
الاعتماديات
أكثر جزء قيمة وأكثر جزء يتم تجاهله في وثائق البنية التحتية.
أثناء الحادث، نادرًا ما يكون السؤال ما الذي تعطل. بل ما الذي تأثر أيضًا، وما الذي يحتاجه هذا الشيء ليعود. ولا يمكن اكتشاف أي منهما من قائمة الخوادم.
وثّق الاعتماديات في الاتجاهين:
النظام | يعتمد على | يعتمد عليه | ترتيب التشغيل | يفشل إذا تعطل الاعتماد |
|---|---|---|---|---|
Order API | Postgres primary وRedis وAuth service | Web app وmobile app وpartner integrations | بعد Postgres وAuth | نعم، فورًا |
Reporting service | Postgres replica | لوحات تحكم داخلية فقط | أي | يضعف ويخدم بيانات مخزنة مؤقتًا |
سببان يجعلانه مفيدًا. ترتيب التشغيل، لأن إعادة تشغيل الأشياء بالترتيب الخاطئ تحول حادثًا قصيرًا إلى حادث طويل. ولأن الاعتماد قد يكون قويًا أو ضعيفًا، فخدمة تتدهور تدريجيًا ليست المشكلة نفسها لخدمة تفشل فورًا.
أدرج الاعتماديات الخارجية. مزودو الدفع ومزودو الهوية وDNS وسلطات الشهادات وواجهات برمجة تطبيقات SaaS تسبب أعطالًا لا يمكنك إصلاحها، ومعرفة ذلك بسرعة تستحق الكثير عند الساعة الثالثة صباحًا.
وثائق الشبكة
العنصر | وثّق |
|---|---|
قطاعات الشبكة | الغرض ونطاق العناوين وVLAN |
التوجيه | بين القطاعات وإلى الإنترنت |
جدران الحماية | مكانها ومن يدير القواعد وكيفية طلب إجراء تغيير |
VPN | نقاط النهاية ومن لديه وصول وكيفية طلب ذلك |
DNS | المناطق ومكان استضافتها ومن يمكنه تغييرها |
موازنات التحميل | ما الذي يقع خلف كل واحدة وسلوك فحوصات الصحة |
الشهادات | ما الذي تغطيه وتاريخ الانتهاء ومالك التجديد وطريقة التجديد |
الاتصال الخارجي | مزودو خدمة الإنترنت والدوائر وجهات الاتصال ومراجع العقود |
يستحق انتهاء صلاحية الشهادات اهتمامًا خاصًا. فهو يسبب أعطالًا يمكن التنبؤ بها بالكامل ويمكن منعها بالكامل، والأرجح بشكل غير متناسب أن تحدث في عطلة نهاية الأسبوع. وثّق ما الذي ينتهي متى، ومن يجدد، وما إذا كان التجديد مؤتمتًا.
Runbooks
الوثيقة التي يفتحها الشخص فعليًا أثناء الحادث.
القسم | المحتويات |
|---|---|
النظام والمالك | مع جهة تصعيد للتواصل |
ما الذي يفعله هذا النظام | فقرة واحدة |
كيف يبدو الوضع الطبيعي | المقاييس والسلوك المتوقع والحمل المعتاد |
التنبيهات الشائعة | ماذا يعني كل واحد وماذا تفعل |
كيفية إعادة التشغيل بأمان | خطوات وترتيب ومتطلبات مسبقة |
أوضاع الأعطال المعروفة | العرض والسبب والحل |
ما الذي لا يجب فعله | الإجراءات التي تجعل الأمور أسوأ |
التصعيد | متى وإلى من |
Runbooks ذات صلة | الاعتماديات |
قسم “ما الذي لا يجب فعله” نادر وقيم. كل نظام ناضج لديه إجراء يبدو منطقيًا ويجعل الحادث أسوأ: إعادة التشغيل بالترتيب الخاطئ، أو مسح ذاكرة التخزين المؤقت التي تستغرق ست ساعات لإعادة بنائها، أو إجراء failover بينما النظام الثانوي خلفه.
اكتب Runbooks لأنظمة المستوى 1 وأي شيء تسبب في حادث. ليس لكل شيء.
الوصول وبيانات الاعتماد
القسم الذي تسبب فيه الوثائق ضررًا بدل أن تمنع الضرر.
لا تضع بيانات الاعتماد أبدًا في الوثائق. لا كلمات مرور، ولا مفاتيح API، ولا سلاسل اتصال تحتوي على أسرار مضمّنة، ولا مفاتيح خاصة. لا في الـ wiki، ولا في ملف Excel، ولا “مؤقتًا”.
وثّق طريقة الوصول. أي نظام يحتفظ ببيانات الاعتماد، ومن يمكنه منح الوصول، وكيف يطلب شخص ما ذلك عند الساعة 3 صباحًا. هذا ما يحتاجه الشخص فعليًا، وهو آمن للكتابة.
بدلًا من | وثّق |
|---|---|
كلمة مرور المسؤول | بيانات الاعتماد في [vault]، متاحة لفريق المنصة، إجراء break-glass في [runbook] |
مفتاح API | مفتاح محفوظ في [secrets manager] باسم [name]، يتم تدويره ربع سنويًا بواسطة [owner] |
تسجيل دخول مشترك | الوصول عبر مجموعة SSO [name]، طلب عبر [process] |
ثم وثّق إجراء break-glass بشكل صحيح، لأن عدم توفر الوصول الطارئ أثناء الطوارئ هو فشل شائع وقابل للتجنب.
استمرارية الأعمال واستعادة الكوارث
ما يجب أن تحتويه وثائق DR ليكون لها قيمة.
أهداف وقت الاسترداد وأهداف نقطة الاسترداد لكل نظام من المستوى 1، متفق عليها مع العمل بدل أن يفترضها فريق تقنية المعلومات. ما هو إجراء الاسترداد فعليًا خطوة بخطوة. أين توجد النسخ الاحتياطية، وبشكل حاسم متى تم اختبار الاستعادة بنجاح آخر مرة. من يعلن وقوع كارثة ومن يستدعي الخطة. كيف يتواصل الفريق عندما تكون الأنظمة الطبيعية متوقفة، لأن خطة DR المخزنة فقط على الأنظمة المتوقفة هي إحراج مألوف.
أهم سطر واحد في أي وثيقة DR هو تاريخ آخر اختبار ناجح للاستعادة. النسخة الاحتياطية التي لم تُستعد أبدًا هي مجرد فرضية.
الرسوم البيانية
تستفيد البنية التحتية من الرسوم البيانية أكثر من معظم أنواع الوثائق، كما أنها تتقادم أسرع.
رسم بياني واحد عالي المستوى يوضح المكونات الرئيسية وكيف تتصل. هذا هو الرسم الذي يستخدمه الناس فعليًا.
طوبولوجيا الشبكة، عندما تكون البيئة معقدة بما يكفي لتحتاجها.
تدفق البيانات، خصوصًا عندما يعبر حدود الثقة أو الولايات القضائية.
حافظ عليها بسيطة. الرسم البياني الذي لا يمكن قراءته بسرعة أثناء حادث هو مجرد زينة.
قم بتأريخها، وضع المالك عليها.
فضّل الرسوم البيانية كـ code عندما سيحافظ عليها فريقك، لأن الرسم في صيغة نصية قابلة للتحكم بالإصدارات يتم تحديثه مع التغيير بدلًا من تحديثه لاحقًا.
الرسم البياني الخاطئ أسوأ من عدم وجود رسم، لأن الناس يثقون بالصور أكثر من النثر.
الحفاظ على الدقة
المشكلة كاملة، والسبب وراء فشل معظم وثائق البنية التحتية.
وثّق أقل. تتناسب الدقة عكسياً مع الحجم. خمس عشرة صفحة دقيقة أفضل من مئتي صفحة قديمة.
اربط تحديثات الوثائق بعملية التغيير. التغيير الذي يغيّر البنية التحتية لا يكتمل حتى تعكسه الوثائق. هذه هي الآلية الوحيدة التي تعمل بشكل موثوق.
أتمتة ما يمكن اكتشافه. يمكن غالبًا توليد الجرد والعناوين والإعدادات والطوبولوجيا. لا يمكن للوثائق المُولدة أن تتقادم بالطريقة التي تتقادم بها الوثائق المكتوبة يدويًا.
اكتب يدويًا فقط ما لا يمكن اكتشافه. الغرض والملكية والأهمية والاعتماديات وأوضاع الأعطال المعروفة وما الذي لا يجب فعله. لا تستطيع الآلات استنتاج أي من هذه الأمور.
أرّخ كل شيء، وأظهر التاريخ بوضوح. تاريخ آخر تحقق ظاهر يساعد القرّاء على معايرة ثقتهم.
راجع حسب جدول زمني حسب مستوى الأهمية، ربع سنويًا للمستوى 1.
صلّحها أثناء الحوادث. اللحظة التي يكتشف فيها شخص أن الوثائق غير صحيحة هي اللحظة التي تكون لديه فيها المعرفة لإصلاحها. اجعلها مهمة تستغرق خمس دقائق، لا تذكرة.
الأتمتة والاكتشاف
يستحق الاستثمار فيه، لأنه يزيل أكبر نمط فشل.
يمكن لِـ قواعد بيانات إدارة التكوين وجرد مزود السحابة ومستودعات البنية التحتية كـ code وأدوات اكتشاف الشبكة أن تولد معلومات دقيقة عن الحالة الحالية بشكل مستمر. أي شيء يمكنها إنتاجه لا ينبغي الحفاظ عليه يدويًا.
الانقسام الذي يعمل: تقوم الآلات بتوثيق ما هو موجود، ويقوم البشر بتوثيق ما يعنيه. يخبرك الجرد المُولّد تلقائيًا أن الخادم موجود وما الذي تم تثبيته عليه. لا يمكن لشخص إلا أن يخبرك أنه هو الذي يجب ألا تتم إعادة تشغيله بين 2 صباحًا و4 صباحًا بسبب تشغيل batch.
عندما تُعرَّف البنية التحتية كـ code، فإن الـ code هو وثائق ما هو موجود. ما يتبقى كتابته هو النية والمعرفة التشغيلية وأوضاع الأعطال.
من يملكها
عيّن الملكية لكل نظام بدل جعل الوثائق مهمة شخص واحد، والتي لا تبقى أبدًا بعد مغادرة ذلك الشخص.
الفريق الذي يشغّل نظامًا يملك وثائقه. شخص محدد بالاسم يملك المعيار العام والقوالب وتيرة المراجعة. وتفرض عملية التغيير تحديثات، لأن الملكية بدون آلية هي مجرد نية.
نمط الفشل هو أن مالك الوثائق يطارد الجميع. هذا يعمل لمدة شهرين تقريبًا.
اختبار الوثائق
ما يعادل اختبار الاستعادة، ويتم تجاهله بنفس القدر.
خذ شخصًا لم يبنِ النظام، وأعطه الوثائق فقط، واطلب منه إكمال مهمة تشغيلية روتينية. إعادة تشغيل مُتحكم بها، أو failover، أو استعادة إلى بيئة اختبار.
كل ما لا يستطيع فعله من خلال الوثائق هو فجوة. كل ما يفعله بشكل خاطئ هو خلل. هذا غير مريح، لكنه الطريقة الوحيدة الموثوقة لمعرفة ما إذا كانت الوثائق ستعمل عند الساعة 3 صباحًا، لأن الشخص الذي كتبها يمكنه دائمًا ملء الفجوات من الذاكرة.
قم بذلك على أنظمة المستوى 1 على الأقل مرة سنويًا، ويفضل ضمن يوم اختبار أو تمرين DR.
أفضل الممارسات
طبّق اختبار الساعة 3 صباحًا على كل شيء قبل كتابته.
وثّق المستوى 1 بشكل صحيح والمستوى 3 بشكل حد أدنى.
اعتماديات في الاتجاهين، مع ترتيب التشغيل.
لا بيانات اعتماد أبدًا، دائمًا طرق وصول.
تاريخ آخر تحقق على كل سجل.
أتمتة أي شيء يمكن اكتشافه، واكتب النية والمعرفة التشغيلية يدويًا فقط.
تحديثات الوثائق تُفرض عبر عملية التغيير.
Runbooks تتضمن ما الذي لا يجب فعله.
اختبارات الاستعادة مؤرخة في خطة DR.
اختبر الوثائق مع شخص غير معتاد، سنويًا.
الأخطاء الشائعة
بيانات الاعتماد في الـ wiki.
كل شيء موثق بنفس العمق، لذلك لا يتم الحفاظ على أي شيء.
اعتماديات موثقة في اتجاه واحد فقط.
لا يوجد ترتيب تشغيل، لذلك تستغرق الاستعادة وقتًا أطول من مدة التعطل.
تفريغات إعدادات قديمة عند الوصول.
رسوم بيانية غير مؤرخة وغير مملوكة، يظل الناس يثقون بها طويلًا بعد أن توقفت عن كونها صحيحة.
الوثائق كمخرجات مشروع، دون تحديث بعدها.
شخص واحد مسؤول اسميًا عن كل شيء.
خطط DR مخزنة على البنية التحتية التي تغطيها.
توثيق النسخ الاحتياطية، لكن لم تُختبر الاستعادة.
لا يوجد تاريخ آخر تحقق، لذلك لا يمكن للقراء الحكم بما يجب الوثوق به.
كتبها الشخص الذي أنشأها، واختبرها لا أحد.
التقاط ما لا يعرفه إلا الشخص الذي بناه
افتح القوالب في Trupeer AI، وطبّق حزمة العلامة التجارية لديك حتى تتطابق الوثائق مع معاييرك، وعدّل أي قسم مباشرة. الإعداد موجود في دليل القالب.
تغطي الأتمتة ما هو موجود. أما ما لا يمكنها التقاطه فهو المعرفة التشغيلية: ترتيب عودة الأشياء، والفحص الذي تقوم به قبل إجراء failover، والسبب الذي يجعل أحدًا لا يعيد تشغيل هذه الخدمة يوم الثلاثاء.
تعيش هذه المعرفة لدى شخص أو شخصين وتغادر عندما يغادران. اجعلهم يشرحون failover أو restore أثناء التسجيل، وينتج Trupeer AI Runbook مكتوبًا وجولة فيديو بصوت الراوي من نفس المرور، بالترتيب الذي يقومون به فعليًا وليس بالترتيب الذي سيتذكرون كتابته.
كما أنها تأخذ وقتًا أقل من وقت كتابتها، وهذا مهم، لأن سبب بقاء المعرفة التشغيلية دون توثيق هو أن الأشخاص الذين يمتلكونها هم الأكثر انشغالًا. ترجمها إلى 65+ لغة للفرق الموزعة، واحتفظ بمجموعة الترجمات في قاعدة المعرفة بجانب الـ runbooks.
سجّلها. اجعلها بعلامتك. ترجمها. اجعلها Trupeer.
الأسئلة الشائعة
هل يوجد قالب مجاني لوثائق البنية التحتية في Word؟
نعم. يحتوي Word على الـ runbooks وخلاصة المعمارية وخطة DR، وهي الأجزاء التي تكون سردية فعلًا. تنزيل مجاني بدون تسجيل وبدون علامة مائية.
هل يوجد قالب مجاني لوثائق البنية التحتية في Excel؟
نعم، وExcel يقوم بمعظم العمل. يتضمن جرد الأنظمة مع مستويات الأهمية وتواريخ آخر تحقق، ومصفوفة الاعتماديات في الاتجاهين، وتفاصيل الشبكة، وتتبع انتهاء صلاحية الشهادات، وجدول المراجعة.
هل يوجد قالب مجاني لوثائق البنية التحتية في PDF؟
نعم، كإصدارات معتمدة وأي شيء يطلبه مدقق أو عميل ليطلع عليه. احتفظ بنُسخ العمل قابلة للتعديل، لأن وثائق البنية التحتية التي لا يمكن تحديثها بسرعة لن يتم تحديثها.
هل يمكنني تنزيل قالب مجاني لوثائق البنية التحتية؟
نعم، كل تنسيق هو تنزيل مجاني بدون الحاجة إلى حساب وبدون نسبة.
هل توجد قوالب مجانية لوثائق تقنية المعلومات؟
نعم. تغطي هذه الصفحة وثائق البنية التحتية تحديدًا. وللوثائق الخاصة بتقنية المعلومات بشكل أوسع، بما في ذلك العمليات والسياسات ومحتوى “كيف”، راجع أمثلة وثائق تقنية المعلومات وقوالبها، ولإجراءات تقنية المعلومات راجع قالب IT SOP.
هل يوجد قالب لوثائق تقنية المعلومات في Word؟
نعم، على صفحة أمثلة وثائق تقنية المعلومات وقوالبها. هذه الصفحة أضيق نطاقًا، وتغطي الأنظمة والشبكات والاعتماديات التي تشكل البنية التحتية لديك.
هل يوجد قالب وثائق مشروع في Word، مجاني للتنزيل؟
نعم، على صفحة قالب وثائق المشروع. تغطي وثائق المشروع نطاق المشروع وخطته ومخرجاته، بينما تغطي وثائق البنية التحتية ما هو موجود في بيئة الإنتاج بغض النظر عن أي مشروع قام ببنائه.
ما هي وثائق البنية التحتية لتقنية المعلومات؟
سجل للأنظمة والشبكات والخدمات والاعتماديات التي تشكل بيئتك، إلى جانب المعرفة التشغيلية اللازمة لتشغيلها واستعادتها. يغطي ما هو موجود، وما يعتمد على ماذا، وكيف يبدو الوضع الطبيعي، وكيف تستجيب عندما يتعطل شيء ما.
ما الذي يجب أن تتضمنه وثائق البنية التحتية؟
جرد نظام مع المالك والأهمية، واعتماديات في الاتجاهين مع ترتيب التشغيل، وتفاصيل الشبكة والاتصال، وRunbooks للأنظمة الحرجة، وطرق الوصول لكن دون بيانات اعتماد، وتفاصيل النسخ الاحتياطي واستمرارية الأعمال واستعادة الكوارث بما في ذلك آخر اختبار ناجح للاستعادة، وتاريخ آخر تحقق على كل شيء.
كيف تحافظ على وثائق البنية التحتية محدثة؟
وثّق أقل، وأتمتة أي شيء يمكن اكتشافه، واربط تحديثات الوثائق بعملية التغيير لديك بحيث لا يكتمل التغيير حتى تعكسه الوثائق. ضع تاريخ آخر تحقق ظاهرًا على كل سجل، وراجع حسب مستوى الأهمية، واترك لأي شخص إصلاح الأخطاء فورًا بدل رفع تذكرة.
هل يجب تخزين بيانات الاعتماد في الوثائق؟
لا. ليست كلمات مرور، ولا مفاتيح API، ولا سلاسل اتصال، ولا مفاتيح خاصة، في أي نظام، مؤقتًا أو غير ذلك. وثّق بدلًا من ذلك أي vault أو مدير أسرار يحتفظ ببيانات الاعتماد، ومن يمكنه منح الوصول، وإجراء break-glass للطوارئ. هذا ما يحتاجه شخص ما فعليًا أثناء حادث، وهو آمن للكتابة.
كم مقدار وثائق البنية التحتية التي يجب أن توثقها؟
يكفي لاجتياز اختبار الساعة 3 صباحًا للأنظمة الحرجة، وقليل جدًا لبقية الأنظمة. تحتاج أنظمة المستوى 1 إلى Runbooks كاملة وخريطة اعتماديات وDR مُختبر. تحتاج أنظمة المستوى 3 إلى صف جرد واحد ومالك. توثيق كل شيء بنفس العمق هو سبب أن معظم وثائق البنية التحتية تنتهي متقادمة.
ما هو Runbook؟
وثيقة تشغيلية لنظام واحد تغطي كيف يبدو الوضع الطبيعي، وماذا تعني التنبيهات الشائعة، وكيف تعيد تشغيله بأمان بما في ذلك الترتيب والمتطلبات المسبقة، وأوضاع الأعطال المعروفة، وما الذي لا يجب فعله، ومتى يتم التصعيد. هي ما يفتحه شخص ما أثناء حادث، ويجب كتابتها لشخص كفؤ غير معتاد على هذا النظام تحديدًا.
كيف توثق الاعتماديات؟
في الاتجاهين، لأنك أثناء حادث تحتاج إلى معرفة ما الذي يتطلبه هذا النظام وما الذي سيتعطل إذا توقف. تضمّن ترتيب التشغيل، وما إذا كانت كل اعتماد قوية أو ضعيفة، واعتماديات خارجية مثل مزودات الهوية وDNS ومعالجات الدفع، والتي تسبب أعطالًا لا يمكنك إصلاحها بنفسك.
كم مرة يجب مراجعة وثائق البنية التحتية؟
حسب مستوى الأهمية: ربع سنويًا للمستوى 1، مرتين سنويًا للمستوى 2، وعند التغيير للمستوى 3. بالإضافة إلى المراجعات المجدولة، يجب أن تفرض عملية التغيير تحديثات، ويجب أن يتمكن أي شخص يكتشف خطأ أثناء حادث من إصلاحه فورًا.
كيف تعرف إذا كانت وثائقك تعمل فعليًا؟
اختبرها. أعط شخصًا لم يبنِ النظام الوثائق فقط، واطلب منه تنفيذ مهمة تشغيلية روتينية مثل إعادة تشغيل مُتحكم بها أو استعادة إلى بيئة اختبار. كل ما لا يستطيع فعله هو فجوة. إنجاز ذلك سنويًا لأنظمة المستوى 1 يعادل اختبار الاستعادة، ويتم تخطيه بنفس القدر من الشيوع.
هل يمكنني تخصيص قالب وثائق البنية التحتية هذا؟
نعم، كل إصدار قابل للتعديل بالكامل. عدّل مستويات الأهمية والحقول وفقًا لبيئتك. الحقلان اللذان يستحقان الحفاظ عليهما هما تاريخ آخر تحقق ورسم خريطة الاعتماديات في الاتجاهين، لأنهما يحددان ما إذا كانت الوثائق موثوقة وما إذا كانت تساعد أثناء حادث.
