SIEM/ELK үшін серверлер: жүктемеге сай диск пен ресурстарды есептеу

SIEM және ELK пилотында проблемалар қайдан басталады

Пилот көбінесе SIEM немесе ELK «жаман» болғандықтан емес, нақты жүктеме басқа болып шығатындықтан бұзылады. Перегруз әдетте мына түрде көрінеді: оқиғалар келеді, бірақ іздеуде кешігіп пайда болады, дашбордтар баяулайды, кейбір журналдар жоғалады немесе түнде ғана «қол жеткізіледі».

Алғашқы белгі — кезектердің өсуі. Алдымен жинақтау буфері толады, содан соң өңдеуде (парсинг, нормализация) жиналады, және ақырында индекаторға дейін жетіп тоқтайды. Сіз «келді» мен «іздеуге қолжетімді» арасындағы үзілуді көресіз. Егер бұл үзілу үнемі өссе, пилот «қарызға кіре» бастайды.

Көбіне пилоттар үш нәрсені бағаламаудан құлайды: нақты EPS, сақтау мерзімі және индексацияның шығындары.

EPS-ті «орташа бойынша» есептеп, шыңдарды ұмытамыз: дүйсенбі күнгі таң, жаппай жаңартулар, инцидент, сканерлеу. Сақтауды «таза журналдар» ретінде бағалаймыз, ал индекс пен жүйелік мәліметтер дискті айтарлықтай ұлғайтады. Индексацияны жай «жазу» деп қарастырамыз, ал шын мәнінде бұл өрістерді талдау, сегменттерді жасау, біріктіру (merge) және кэштеуді де қамтиды.

Әдеттегі архитектурада төрт бөлік бар: жинау (агенттер мен коллекторлар), өңдеу (пайплайндар), іздеу мен талдау (индекстер мен сұраулар) және сақтау (дискілер, репликалар, бэкаптар). Тар жер кез-келген жерден шығады, бірақ бірінші болып жиі индексация түйінідегі дискілер мен CPU бермейді.

Пилот алдында келесі жайларды келісіп алған жөн: қанша узел деректерді қабылдап индекстейтін болады және рөлдер қалай бөлінеді; қандай дискілер үздіксіз жазу мен фондық операцияларды ұстай алады; сақтау схемасы қандай болады (жылдам іздеу үшін "жылы" деректер және тарих үшін арзанырақ сақтау); диск не узел істен шыққанда қалай өту керек (репликация, RAID, резервтік көшірме).

Типтік сценарий: банк пилоты «бірнеше көзден» басталады, ал апта өткеннен кейін VPN, AD, EDR және желілік құрылғылар қосылады. EPS бірнеше есе өседі, ал серверлер индексация бойынша ілгекке түсе бастайды, тіпті жалпы дискілік сыйымдылық бірдей болғанда да.

Есептеу үшін қандай бастапқы деректер керек

SIEM/ELK инфрақұрылымын таңдау және пилотта шектеліп қалмау үшін алдымен бірнеше есепті жинаңыз. Бұларсыз диск пен ресурстарды есептеу болжамға айналады.

Минимальды бастапқы жиын:

• Әрбір түрдегі көз бойынша EPS: желілік құрылғылар, AD, EDR, қосымшалар серверлері, дерекқорлар.
• Оқиға орташа өлшемі (байтпен) және «ауыр» журналдардың үлесі (мысалы, Windows Security, прокси, EDR).
• Сақтау мерзімі: қанша күн «жылы» деректерді іздеу үшін сақтау керек және қанша күнді «суыққа» көшіруге болады.
• Іздеу мен аналитика жүктемесі: қанша қолданушы, қандай дашбордтар, корреляциялар мен есептер қаншалықты жиі жүреді.
• Қалпына келтіру терезесі: жүйе қандай уақытқа дейін қолжетімсіз болуы мүмкін және логтарды «кезекке» қабылдау керек пе.

EPS-ті «аспаннан» алмаңыз. Оны әдетте үш тәсілдің бірімен алады: бар SIEM статистикасын қарау (егер бар болса), коллекторлар мен агенттерден 7–14 күнге метрикалар жинау немесе шоғырландырғышта (syslog/agent) қысқа өлшеу жүргізу (шың уақыттарында). Орташа мен шыңды тіркеу маңызды: пилоттар көп жағдайда шыңнан құлайды.

Оқиға өлшемі де ауытқиды. Бір көз қысқа жүйелік жолдар жазады, ал сирек, бірақ өте үлкен оқиғалар (қосымша қателері stack trace-пен, EDR оқиғалары, көптеген өрістер бар DNS/Proxy) болады. Медиана мен 95-процентиль өлшемін алу пайдалы.

Сақтау мерзімдері бойынша алдын ала «жылы» не екенін анықтаңыз. Көп таралған шешім — тез тексеріс үшін 7–14 күн, қалғанын арзанырақ сақтауқа көшіру. Реттеуші талаптар мен ішкі қауіпсіздік талаптарын жеке тексеріңіз.

Мысал: банк пилоты 50 көзбен және орташа 3 000 EPS-пен басталады, бірақ жұмыс уақытында шыңдар 10 000 EPS-ке жетеді. Егер SOC дашбордтарды күн бойы ашық ұстаса және корреляциялар әр 5 минут сайын іске қосылса, CPU мен жылдам дискілерге талаптар сирек қолмен іздеулерге қарағанда жоғары болады.

Деректер көлемін есептеу: EPS-тен терабайтқа дейін

EPS-тен сақталатын көлемге көшу үшін базалық есептеуден бастаңыз:

Күнделікті көлем = EPS x орташа оқиға өлшемі (байт) x 86 400.

Мысалы, 2 000 EPS және орташа 500 байт болса: 2 000 x 500 x 86 400 = 86,4 ГБ/күн (накладты шығындарды есептемегенде).

Практикада «таза» лог байттар ғана бастама. Көлем пиктерге, байытуға және стекіңіздің өз накладтарына байланысты өседі. Тура есептеу қиын болғандықтан көбіне коэффициенттер арқылы қарау ыңғайлы.

Көлемді көбейтетін ең жиі факторлар:

• жүктеме шыңдары (апаттар, сканерлеулер, жаңартулар, инциденттер);
• парсингтен кейін оқиғаның өсуі (қосылған өрістер, тегтер, гео, user-agent);
• индекс накладтары (жылдам іздеуге арналған құрылымдар);
• жүйелік және компонент журналдары (Elasticsearch, Logstash/Beats, ОС).

Сығу көмектеседі, бірақ оған «5 есе» деген сияқты сенуге болмайды. Ол көзге байланысты: біртектес оқиғалар жақсы сығылады, ал әртүрлі форматтағы (audit, EDR, прокси) әдетте нашар сығылады. Қауіпсіз жақтан консервативті диапазон қолдану дұрыс.

Өзексіздік (отказоустойчивость) орын мөлшерін тікелей көбейтеді. Реплика 1 деректерді шамамен екі есе көбейтеді, реплика 2 — үш есе. Сонымен қатар шардтарды қайта орналастыру кезінде қажет орынды ескеріңіз: кластер бір узел құлағаннан кейін дискілер 90–95% шегіне тез жетпеу керек.

Тағы ұмытылатын нәрселер: снапшоттар (индекстердің резервтік көшірмелері), слияние кезінде уақытша файлдар, сондай-ақ жүйелік индекстер мен журналдарға арналған тұрақты орын. Тіпті снапшоттар бөлек болса да, олар үшін уақытша және ресурстық терезелер қажет, сондықтан оларды да алдын ала жоспарлау жақсы.

Индексация мен іздеу: серверлерді ең көп не жүктейді

SIEM/ELK-та көбіне «көлем емес», ал өңдеу жылдамдығы мәселе болады: деректер қабылданып, талданып, индексделіп, іздеуге қолжетімді болуы керек. Сондықтан сервер таңдауында тек терабайт емес, CPU, RAM және дискілік подсистема маңызды.

Индексация CPU мен RAM-ды жүктейді, себебі Elasticsearch (және ұқсас қозғалтқыштар) үнемі көптеген кішкентай операцияларды орындайды: өрістерді талдау, іздеу құрылымдарын жасау, сегменттер жазу және оларды кейін біріктіру (merge). Шың уақыттарында немесе белсенді дашборд кезінде бұл әдетте CPU-ның жоғары жүктемесі, кэш пен жүйелік құрылымдарға арналған жадының өсуі және дискідегі кішкентай жазбалар кезегінің көбеюі ретінде көрінеді.

«Жылы» деректер (соңғы сағаттар немесе күндер) әдетте жылдамдықты талап етеді. Мұнда IOPS пен кешігу «таза» терабайттан маңызды: үлкен сыйымдылықтағы баяу диск шың уақытында жазу, merge және сұраулар бірге жүргенде тез тар ағып қалады.

Hot-warm-cold схемасы ұзақ сақтау және сирек сұралатын ескі деректер болғанда көмектеседі. Пилотта бұл көбіне артық күрделілік әкеледі: қосымша узелдер, индекстерді тасымалдау ережелері және қатені енгізу мүмкіндіктері көбейеді. Сондықтан басында қарапайымдан бастау және жүктеме профильін түсінгеннен кейін қабаттарды қосу пайдалы.

Шардтар мен репликалар параллелизм мен отказоустойчивті береді, бірақ «мадырақ» кесу қауіпті. Көп кішкентай шардтар жад пен басқаруға наклад әкеледі, және кластер өзі-өзін қызмет көрсетуге көп ресурсын жұмсай бастайды.

Өнімділікке көбіне әсер ететіндер:

• ауыр сұраулар: көп өріс, агрегациялар, күрделі дашбордтар;
• жиі қайтаиндексация және парсингті «ұшақта» өзгерту;
• бір узелге тым көп шардтар;
• баяу дискілерге репликация;
• hot қабатта IOPS жетіспеушілігі.

Жад туралы: үлкен RAM пайдалы, бірақ «heap-ті жай ғана үлкейту» әрқашан көмектеспейді. Егер heap-ке тым көп берсеңіз, файлдық кэшке орын қалмайды да, дискіден оқу көбіреді. Көп жағдайда алдымен CPU және IOPS-ті теңестіру, ал RAM-ды нақты сұрауларға қарай арттыру дұрыс шешім.

Дискілерді таңдау: жылдамдық, сенімділік, баға

SIEM/ELK-та дискілік подсистема жиі CPU-дан бұрын шектеледі. Оқиғаларды қабылдау үздіксіз жүріп, индексация мен іздеу көптеген кішкентай операциялар жасайды. Сондықтан сыйымдылықтан басқа кешігу мен IOPS маңызды.

Практикалық модель — деректерді жылы және суыққа бөлу.

Жылы қабат жаңа журналдарды қабылдап, белсенді индексдеп, жиі сұрауларға жауап береді. Мұнда SSD міндетті, жақсырақ NVMe: төмен кешігу жазу кезегін азайтады және шыңда «тұншығуды» болдырмайды.

Суық қабат ескі индекстерді сақтайды, оларға жазу аз және іздеу сирек жүреді. Онда HDD-ді қолдануға болады, егер архивке баяу іздеуге әзір болсаңыз.

NVMe жиі 7–30 күнге жылы буфер ретінде қолданылады: жаңа деректер тез ізделеді, содан кейін сақтау саясаты бойынша арзанырақ қабатқа жылжиды. Бұл баға мен жылдамдықтың жақсы тепе-теңдігін береді, әсіресе EPS тұрақсыз болса.

RAID таңдау тапсырмаға байланысты: жылдамдық, сыйымдылық немесе диск істен шыққанда төзімділік. Көбінесе қолданылатын үш нұсқа: RAID 10 (болжамды кешігулер мен жазба, бірақ сыйымдылықтың жартысы айнаға кетеді), RAID 6 (көбірек пайдалы орын және екі диск істен шықса да өмір сүре алады, бірақ жазу мен қалпына келтіру ауыр), RAID 0 (жылдам, бірақ тек уақытша буферлер үшін жарамды — деректер жоғалса қабылданады).

"Тар орын" болдырмау үшін диск түрінен басқа жазу жолын да тексеріңіз. Мәселелер жиі контроллер немесе HBA, узелдер арасындағы желі, шардтар мен кішкентай сегменттердің көптігі, сондай-ақ диск почти толы болғанда фондық операциялардың өнімділікке қатты әсер етуінен шығады.

Егер болжамдылық керек болса, резерв қойып, пилотты нақты сценарийлерде тексеріңіз: шың EPS, параллельді іздеу, индекстерді айналдыру және диск істен шыққаннан кейін қалпына келтіру.

Сервер схемасы: рөлдер мен узелдер, қажетсіз күрделіліксіз

Пилот үшін де узел схемасынан бастаңыз. Қате — барлық рөлдерді бір-екі серверге жинап, кейін оқиғалар мен іздеуде жоғалтулар алу.

Рөлдерді былай қарастырған дұрыс: біреулер деректерді қабылдайды және дайындайды, басқалар сақтайды және индекстейді, тағы басқалары кластердің өміршеңдігін бақылайды, ал қалғандары қолданушы сұрауларын қызмет етеді.

Өсуге төзетін минималды узелдер

Кішкентай көрсетілім үшін бір узел жеткілікті болуы мүмкін. Пилот, ол қайта жүктеуді, жаңартуды және жүктеме өсуді ұтатын болуы керек болса, көбінесе келесі схемалар қолданылады:

• 3 узел — рөлдер біріктірілген (жылдам бастау, бірақ масштабтау қиындау);
• 5 узел — 3 master (кластерді басқару) + 2 data (сақтау және индексация);
• 6–7 узел — қосымша 1–2 ingest (қабылдау мен парсинг) және белсенді дашборд болғанда 1 coordinator (іздеу мен агрегация).

Master-узелдер ауыр деректерді ұстамауы керек. Олардың міндеті — кластер тұрақтылығын сақтау. Data-узелдер әдетте ең жүктелген: диск, CPU және индексацияға RAM қажет. Ingest көп көздер, нормализация және буфер қажет болғанда пайдалы. Coordinator қолданушылар белсенді іздегенде сұраулардың data-узелдерді «тығылтпауы» үшін көмектеседі.

Желі: сатып алудан бұрын не тексеру керек

Желі мәселелері жиі «дискілер жеткіліксіз» дегенге ұқсай көрінеді. Бастапқыда узелдер арасындағы және коллекторларға дейінгі нақты өткізу қабілетін, кешігулер мен пакет жоғалтуларды шың уақыттарында, сонымен қатар журнал қабылдау трафигі мен іздеу трафигінің қалай бөлінетінін тексеріңіз (басқа сөзбен айтқанда, логикалық түрде). Болашақ узелдер мен балансировканы ескеріп порты мен коммутацияда резерв ұстау пайдалы.

Идентификация, метрика мен мониторинг үшін бөлек сервер қажет болады, егер индексация ресурстарын бөліскім келмесе. Метрикалар, алерттер, бэкаптар, жаңартулар және тест жұмыстарын кластерден шығару дұрыс.

Конфигурацияны таңдау қадамдары

Жүйе пилотта шектелмесін десеңіз, конфигурацияны жүктеме мен сақтау ережелері бойынша есептеңіз, «шамалап жетеді» деген сезімнен емес. Бұл методиканы әдетте ИБ мен ИТ арасында 1–2 кездесу ішінде өтуге болады.

1. Әрбір көз бойынша орташа және шың EPS-ті белгілеңіз.

2. Оқиға өлшемін бағалаңыз. Жай бағалау үшін жиі 0,8–1,5 КБ/оқиға алынып, байыту мен индекс накладтарына қор қосылады.

3. Ағынды сақтау көлеміне аударыңыз: EPS x өлшем x 86 400. Содан кейін шыңдар мен өсімді ескеру үшін кепіл коэффициентін (көбіне 1,3–2,0) қосыңыз.

4. Сақтауды қабаттар мен мерзімдер бойынша бөлу. Мысалы: 7 күн hot, 30 күн warm, 180 күн cold. Әзірге қабаттар қажет болмаса, бір ғана жылы қабатпен бастап, пилоттағы сақтау мерзімін шектеу шынайы.

5. Репликалар мен индекс накладыларын ескеріңіз. Практикада «таза» деректерге жиі тағы +30–50% қосады.

6. Узел рөлдерін бөліңіз. Пилотта бір "универсал" серверге бәрін жинау қауіпті: қабылдау, парсинг, индексация және іздеуді бірдей орындау.

7. Жүктеме сынағын өткізіңіз. Шың EPS-ті 1–2 сағатқа имитациялап, жеткізу кешігуін, индексация жылдамдығын және кезектердің өсуін тексеріңіз. Егер троттлинг, merge-аудандары, threadpool-да rejected немесе кэшке жады жетпеу көрінсе, конфигурацияны түзетіңіз: hot-узелдер қосыңыз, дискілерді өзгертіңіз, сақтау мерзімі мен шард өлшемін қайта қараңыз.

Есептеулер мен пилоттаудың типтік қателері

Пилоттың құлау себебі — «көксіну жайтында терабайт аз» емес, накладты шығындарды ұмытып кету. Тек «таза» журналдарды есептеп, кейін дискілер екінші аптада таусылады. Көлемге репликалар, жүйелік индекстер, уақытша сегменттер және сығу әсер етеді.

Екінші ауыртпалық — дискі жылдамдығы. Орын жеткілікті болуы мүмкін, бірақ жазу үлгермей қалады: кезектер өседі, кешігулер пайда болады, дропаулар пайда болады, және қабылдау «түсіп қалады». Көбіне себебі — жылы индекстерді HDD-ге қою немесе жазу мен ауыр іздеуді бір баяу массивке араластыру және IOPS резервінің жоқтығы.

Үшінші қате — "барлығын бір серверге қою". SIEM/ELK үшін бұл әдетте тұзақ: пилот тез продқа айналады да, миграция ауыр болады. Тіпті бір узелден бастасақ та, рөлдерді қалай тарату және узел қосу жоспары болуы керек.

Тағы бір жасырын проблема — шард өлшемін дұрыс таңдамай қою. Көп кішкентай индекстер жад пен CPU-ға артық жүктеме береді, ал тым үлкен шардтар іздеуді және қалпына келтіруді баяулатады. Сонымен қатар өсуді ұмытамыз: жаңа көздер, қосымша өрістер, ауыр форматтар қосылады, және өткендегі EPS есептемесі ескіреді.

Пилотты жиі резервтік көшірме және қалпына келтіру жоспарысыз іске қосады. Кейін шаблондар қатесі немесе диск істен шығуы болғанда, қалпына келтіру күндерге созылатыны анықталады.

Бастамас бұрын қысқа тексеруден өтіңіз: есептелген көлемді реплика мен жүйелік деректерді қосып көбейтіңіз және резерв қосыңыз; дискілер шың жазуды көтеретінін тексеріңіз; шард пен индекстер ротациясын бекітіңіз; 6–12 айға өсім болжамын қосыңыз; бэкап пен RTO/RPO сценарийін анықтаңыз.

Сатып алудан және іске қосудан бұрын жылдам тексерістер

Сатып алудан бұрын бірнеше жылдам тексеріс жасау пайдалы. Олар көбінесе апта-апта уақытты үнемдейді, себебі «орташа бәрі қалыпты болды», бірақ шыңда журнал қабылдау сағаттар бойынша кешігіп қалғаны белгілі болады.

Шынайы оқиғалар санын растаңыз: EPS пен шыңдарды кемінде апта бойы, жақсырақ ай бойы өлшеңіз. Маңыздысы — тек максимумды емес, жүктеме формасын көру: қысқа шыңдар (жаңартудан кейін) және жұмыс уақытындағы ұзақ жоғары фон.

Көлемді резервпен тексеріңіз. Elasticsearch тек «таза» журналдардан өсіп қана қоймайды: орын репликалар, снапшоттар, жүйелік деректер мен индексация накладыларымен әжептәуір көбейеді. Егер 30 күн сақтау жоспарласаңыз, 45 күндегі сценарийді де есептеңіз, сол арқылы өсу немесе кеңейту кешігулерін басынан өткермейсіз.

Практикалық минимум:

• EPS пен шыңдарды өлшеңіз, негізгі көздер мен форматтарды тіркеңіз;
• дискі есептеулерін репликалар, снапшоттар және өсу резервімен тексеріңіз;
• стендте жазуды және жылы деректер бойынша жылдам іздеуді тесттеңіз;
• мақсатты көрсеткіштерді келісіңіз: қабылдау кешігуі, іздеу уақыты, RPO және RTO;
• тоқтатусыз кеңейту жолын ойлаңыз: узелдер мен дискілерді кезең-кезеңімен қосу.

Мысал: банктегі пилот 3–5 мың EPS-та жұмыс істейді, бірақ аптасына бір рет SOC ауыр сұрауларды іске қосады. EDR шыңдарының фонында жылы индекстерге жазу жинала бастайды. Егер «шың + іздеу» сценарийін алдын ала сынап, IOPS резервін қоссақ, пилот басқарылатын болады.

Мысал есеп: банк немесе мемлекеттік орган үшін пилот

Әдеттегі пилот алайық: күніне орташа 5 000 EPS, шыңдар 12 000 EPS-ке дейін жетеді. Оқиғаның орташа өлшемі — 800 байт (парсингтен кейін өсуі мүмкін). Сақтау талабы: 30 күн hot, 180 күн cold, реплика 1 (деректердің екі көшірмесі), плюс күнделікті снапшоттар.

Қанша орын керек

«Таза» ағынды есептейміз: 5 000 EPS x 800 байт = 4 МБ/с. Күнделікті шамамен 345 ГБ.

Содан кейін Elasticsearch накладыларын қосамыз. Пилот үшін коэффициент ретінде 1,3–1,5 қауіпсіз. Біз 1,4 алайық.

• Hot 30 күн: 345 ГБ/күн x 30 = 10,4 ТБ таза. 1,4 коэффициентімен: 14,6 ТБ. Реплика 1 екі есе етеді: шамамен 29 ТБ.
• Cold 180 күн: 345 ГБ/күн x 180 = 62 ТБ таза. 1,4 коэффициентімен: 87 ТБ. Репликамен: шамамен 174 ТБ.

Өсу резервін (әдетте 20–30%) және жүйелік орын қосқанда, егер cold деректерді де Elasticsearch-та репликамен сақтау жоспарланса, пилот оңай 250 ТБ шамасындағы «грязный» сыйымдылыққа шығады.

Снапшоттарды бөлек есептеген жөн. Күнделікті көшірмелер үшін бөлек сақтау және бірнеше циклға арналған орын керек.

Рөлдер мен дискілерді қалай бөлу

Пилоттың шыңда «айрылмай қалмауы» үшін қабылдау мен өңдеуді data-узелдерден бөліп қою пайдалы. Практикалық минимум: ingest (қабылдау, парсинг, нормализация) бөлек, ал data (сақтау, индексация) бөлек. Hot қабат үшін NVMe разумды (жазу мен merge-қа төмен кешігу), cold үшін үлкенірек диск, ал снапшоттар үшін бөлек контур бөлген дұрыс.

Пилотта графиктер емес, ауырлық белгілерін тексеріңіз: қабылдау кезегі (Logstash/ingest) және жеткізу кешігуінің өсуі; Elasticsearch threadpool bulk/write және rejected саны; IOPS пен диск кешігуі (әсіресе hot); refresh/merge уақыты мен сегменттердің өсуі; снапшоттан қалпына келтіру нақты жылдамдығы.

Келесі қадамдар: пилоттан тұрақты жүйеге өту

Пилот көбіне болжамдарға сүйенеді: орташа EPS, «шамамен» оқиға өлшемі, сақтау мерзімдері. Сюрприз болмас үшін бұл болжамдарды қарапайым кестеге түсіріп, жүйе иелері мен қауіпсіздікпен келісіңіз. Тек сандарды емес, қай жүйелер контурда екенін, не алынып тасталатынын және қандай журнал критикалық екенін жазыңыз.

Содан кейін қысқа жүктеме сынағын өткізіңіз: 2–4 сағат, бірақ нақты шыңдарға ұқсас. Нәтижесінде коэффициенттер нақтыланады: парсингтен кейінгі орташа оқиға өлшемі, дискідегі нақты сығылу, «шу» көздерінің үлесі, индексация жылдамдығы мен кезектердегі кешігулер.

Одан кейін пилот 6–12 айға өсу жоспарына айналады. Ол бір сұраққа жауап беруі тиіс: EPS екі еселенсе немесе жаңа көздер қосылса не істейміз? Көп жағдайда бұл «бәрін ауыстыру» емес, узелдер қосып, сақтауды үлкейту.

Шешімдерді қысқа чеклист түрінде бекіту пайдалы: қандай метрикалар қызыл аймақ саналады (кезектер, индексация кешігуі, диск толуы, парсинг қателері); узелдерді қалай және қашан қосатындығы (шектіге байланысты немесе кестеге сай); қайда сақталады резервтік көшірме және қалпына келтіру уақыты; кім 24/7 дежурит және қандай әрекеттер келісімсіз жасауға болады; қалпына келтіру қалай тексеріледі ("бэкап бар" емес, "біз оны көтеріп, іздеуді аштық").

Егер жобада Қазақстан ішінде жабдық пен қолдау маңызды болса, алдын ала кім жабдықты және сервисті қамтамасыз ететінін ойлаңыз. Мұндай жағдайларда жергілікті өндіруші мен интеграторлар — мысалы, GSE.kz сияқты — ыңғайлы: жүктемеге сәйкес конфигурацияларды, кеңейту жоспарын және сервистік үйлесімділікті алдын ала келісуге болады.