Open source-қа көшу қателері: 12 сәтсіздік және контршаралар

Неліктен open source-қа көшу сәтсіздікке ұшырайды

Open source-тан әдетте шығынды қысқарту, вендорға тәуелсіздік және икемділік күтеді. Бірақ алдын ала қолдау, оқыту және жұмыс ережелерін ойластырмасаңыз, нәтиже керісінше болуы мүмкін: тоқтап қалулар, пайдаланушылардың ренжуі және жасырын шығындардың көбеюі.

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

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

Көбінесе алаңдаушылық маркерлері мыналар:

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

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

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

Жоба жоспарына контршараларды қалай енгізу: қадамдық скелет

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

Жобаны ұстайтын жоспар скелеті

Ең алдымен мақсат пен өлшенетін критерийлер туралы келісіңіз. «Ақша үнемдеу» немесе «вендордан кету» дұрыс естіледі, бірақ іске қосу күні көмектеспейді. Нақты көрсетілген дұрыс: қанша жұмыс орнын ауыстырасыз, қандай қосымшалар міндетті түрде жұмыс істеуі керек, қабылданатын тоқтау уақыты қандай, қандай метрикаларды қалыпты санайсыз (кіру уақыты, принтер, құжаттармен жұмыс, қолдау сұраулар саны).

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

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

Контрмер ретінде не енгізуге болады

Жоспарға алты блокты енгізу ыңғайлы:

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

Пилоттан кейін табылған мәселелерді түзетіп, тек содан кейін ғана қамтуды кеңейтіңіз. Ал іске қосқаннан кейін жобаны сол күні «жабуға» болмайды: жаңа шешімнің бекітуі үшін 2–4 апта күшейтілген қолдау мен метрика қайта қарауын жоспарлаңыз.

1–2 сәтсіздік: оқыту және өзгерістерді басқару

Open source-қа көшу кезінде ең жиі кездесетін қателіктердің бірі — адамдар «өздері үйренеді» деп ойлау. Нәтижесінде қызметкерлер ескі әдеттерін сақтайды: файлдарды басқа жерге қояды, жаңа ережелерден ауытқиды, ал қолдау қызметіне тек іске қосу алдындағы соңғы күні келеді.

Сәтсіздік 1: оқытуды кейінге қалдыру

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

Қарапайым контрмера: оқыту пилот пен іске қосу күнтізбесімен бірге жоспарланады және рөлдер бойынша өткізіледі. Әдетте жеткілікті:

• пайдаланушыларға — 3–5 типтік сценарий (құжаттар, пошта, бірлескен жұмыс) және қысқа кеңестер
• әкімшілерге — орнату, жаңарту, бэкап, мониторинг, типтік инциденттер
• қолдау қызметіне — жиі сұрақтарға арналған шпаргалкалар, жауап шаблондары, эскалация критерийлері
• басшыларға — процестерде не өзгереді және әсерді қалай өлшеу керек

Бастапқы 1–2 аптада «кеңес сағаттары» қоссаңыз пайдалы: сұрақты тез қоюға және жауап алуға мүмкіндік береді.

Сәтсіздік 2: өзгерістерге және коммуникацияға иесі жоқ

Ешкім өзгерістер үшін жауап бермесе, техкоманда өз бөлігін жасап, пайдаланушылар жаңалықтар туралы кездейсоқ білетін болады. Сол кезде қауесеттер, әртүрлі ережелер мен қарсылық пайда болады: «бізге ештеңе түсіндірмеді».

Контрмера: өзгерістер иесін тағайындаңыз (әдетте жоба жетекшісі немесе бөлек change-менеджер) және қарапайым коммуникация жоспарын бекітіңіз: нені хабарлаймыз, кімге, қашан және қай арналары арқылы. Практикада қысқа ритм жақсы жұмыс істейді: хабарландыру, апта бұрын еске салу, күн бұрын нұсқаулық, іске қосу күні қолдау, 3–5 күннен кейін кері байланыс жинау.

Мысал: мемлекеттік ұйымда бөлімді жаңа офис пакетіге ауыстырғанда алдын ала 1 беттік ескерту жіберіп, қолдауға сауал шаблондары беріп және әр кабинетке «чемпион» тағайындасаңыз, іске қосу күні критикалық инциденттер саны айтарлықтай азаяды. Ал күрделі инфрақұрылымда 24/7 пайдаланушыларды кім қолдайтынын алдын ала шешу маңызды: ішкі қызмет пе, интегратор ма.

3–4 сәтсіздік: инвентаризация, талаптар және үйлесімділік

Сәтсіздік 3: «офисті» көшіреді, ал маңыздысы кейін шығады

Сіз «офисті» аударасыз, ал кейін күтпеген маңызды Excel-макросы, ескі бухгалтерлік утилита немесе бір адам ғана еске алатын мемлекеттік порталмен интеграция шығады. Мерзімдер қисайып, команда өрт сөндірумен айналысады, және open source-қа көшу қателері «қажетті» сияқты көріне бастайды. Себеп жиі тізімдердегі олқылықтар.

Контрмера — қысқа бірақ толық инвентаризация және маңызды деңгейін белгілеу. Көп жағдайда бір кесте жеткілікті: қосымшалар мен нұсқалар (кішкентай утилиттерді қоса), қолданушылар топтары мен рөлдер, интеграциялар мен деректер алмасу (пошта, ЭДО, 1С, домен, принтер), периферия (принтерлер, сканерлер, токендер, МФУ), қабылданатын тоқтау уақыты.

Параллельде талаптарды бекітіңіз, дауға түспеу үшін: мақсат мерзімдер, шықиңдық күндері, тоқтау терезелері, қауіпсіздік және деректерді сақтау талаптары, кім қабылдауды қол қояды.

Сәтсіздік 4: үйлесімділікті «жалпы» тексеріп, нақты кейстерде тексермеген

Содан кейін белгілі болады: нақты принтерге драйвер жоқ, құжаттарға қол қою жұмыс істемейді немесе файлдар ашылады, бірақ формат «бұзылады».

Контрмера — үйлесімділік матрицасы және типтік тапсырмалар бойынша жылдам тесттер. Сатып алу бөлімі үшін бұл — келісімшарт шаблондары, қажетті лотокқа басу, есеп жүйесіне импорт, ЭЦП-пен жұмыс. Минималды тексеру жиынтығына көбік принтерлерде басып шығару мен сканерлеу, негізгі құжат форматтарымен жұмыс, кіру және құқықтар (жағымды папкалар, поштаға қолжетімділік), токендер мен маңызды порталдар, сондай-ақ 3–5 типтік қолданушыға «бір күннің» тесті кіруі тиіс.

Егер техника алуан түрлі болса, алдын ала «референс» жұмыс орындарын таңдап, соларда сынақ өткізіңіз. Қалғаны үшін жаңарту немесе ауыстыру жоспарын анықтап, продқа сюрприз шықпауын қадағалаңыз.

5–6 сәтсіздік: интеграциялар және заңдық аспектілер

Сәтсіздік 5: ядро көшті, күнделікті жұмыс тоқтады

Адамдар SSO арқылы кіре алмайды, құжаттарды басып шығара алмайды, хаттар шықпайды, 1С-пен немесе ЭДО-мен алмасу «қатты емес» жұмыс істейді. Нәтижесінде проблемалар «open source қателері» деп қабылданады, ал шын мәнінде тәуелділіктер алдын ала сипатталмаған.

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

Көбіне ұмытып кететіндер: пошта мен күнтізбе (хабарламалар, таралымдар, шақырулар), ЭДО, 1С, СЭД/архив, SSO және басып шығару (аккаунттар, құқықтар, кезектер, драйверлер).

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

Сәтсіздік 6: лицензиялар мен құқықтарды соңғы сәтте есіңізге түсіру

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

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

7–8 сәтсіздік: деректер, форматтар және жұмыс әдеттері

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

Сәтсіздік 7: деректерді тасымалдау ережесіз жүргізілді

Дубликаттар, «жоғалған» жазбалар, қате өрістер және бір объектінің әртүрлі нұсқалары пайда болады. Мысалы: CRM немесе кадрлар жүйесінде кей даталар басқа форматта келді, статустар сәйкес келмеді, бір қызметкер әртүрлі идентификаторлармен екі рет тіркелді.

Одан қорғану үшін алдын ала миграция ережелерін бекіту және тасымалдаудан бұрын және кейін деректер сапасын тексеру керек. Open source көшу жоспарына өрістерді сәйкестендіру (mapping), тазалау және дедупликация (және жауапты), сапа бақылауы (тексеру таңдамалары, қорытындыларды салыстыру, қабылданатын ауытқулар), өзгерістер журналы және тоқтату критерийлері енгізілуі тиіс.

Жүктеу алдында міндетті тармақ — бэкаптар және қалпына келтіруді тексеру. Бәрін «бэкап жасадым» деп айту жеткіліксіз: тесттік контурда бір рет қалпына келтіріп, деректердің тез және толық көтерілуін тексеріңіз.

Сәтсіздік 8: құжат форматтары мен бірлескен жұмыс бұзылады

Шаблондар, макростар, фирмалық бланктер, күрделі кестелер, бірлесіп редакциялау және баспа формалары басқаша жұмыс істей алады.

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

9–10 сәтсіздік: қауіпсіздік, қолжетімділік және сәйкестік

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

Сәтсіздік 9: құқықтарды шашып берді

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

Контрмера тәртіп талап етеді: алдымен рөлдер мен топтар, содан кейін құқықтарды беру. Минималды артықшылық принципінен бастаңыз және жүйеде кімнің не істейтінін емес, кімнің қалай істейтініне тіркеу жүргізіңіз. Іске қосқаннан 2–4 аптадан кейін қысқа аудит өткізіп, артық немесе жетіспейтін құқықтарды анықтаңыз.

Детальдарда адаспау үшін жоба жоспарына енгізіңіз: рөлдер мен рұқсаттар матрицасы; құжатталған сұрау процесі және құқықтардың берілу мерзімі; топтар мен аккаунттарды тұрақты тексеру (соның ішінде жұмыстан кеткендер); парольдерге, MFA және әкімшілерге базалық талаптар; негізгі әрекеттерді журналдау (кіру, құқық беру, деректер экспорттары).

Сәтсіздік 10: сәйкестік (комплаенс) іске қосқаннан кейін есіңізге түседі

Логирование, сақтау мерзімдері, реттеуші талаптар мен ішкі регламенттер тек қымбат өзгеріс қажет болған кезде ғана еске түседі. Бұл әсіресе мемлекеттік сектор, қаржы және медицинада маңызды.

Контрмера: қауіпсіздік талаптарын алдын ала жинап, пилотқа дейін келісіңіз. Ішкі саясаттар, аттестациялар, логтар мен бэкаптарды сақтау талаптары қабылдау критерийлеріне енгізілуі тиіс.

Шұғыл жағдайға әрекет жоспарын да қосыңыз: хабарламаны кім қабылдайды, жүйені оқшаулауға кімнің құқығы бар, логтарды қайдан қарау керек, әрекеттер қалай тіркеледі және қалпына келтіруге кім рұқсат береді. IT және ҚА бөлімдерінен жауаптылар тағайындап, іске қосар алдында кемінде бір «сухой» жаттығу өткізуге көмектеседі.

11–12 сәтсіздік: тестілеу, қабылдау және откат жоспары

Сәтсіздік 11: «орнатылды — іске қосылды — демек жұмыс істейді»

Open source-қа көшу барысында қателік орнатуда емес, жұмыс сценарийлерінде: басып шығару, құжат шаблондары, желілік папкаларға қолжетімділік, қол қоюлар, арнайы макростар, шыңғы уақыттағы жұмыс. Егер бұл алдын ала тексерілмесе, мәселелер іске қосқаннан кейін шығады да, қателіктің бағасы ең үлкен болады.

Контрмера — функцияларды емес, бизнес-процестерді тестілеу. Қалыпты тест жоспары рөлдер бойынша сценарийлерді, күтілетін нәтижені, жүктеме (таңертеңгі шыңдар мен есеп дайындау алдындағы уақыттар), периферияны, ажырату жағдайларын (тор ажырауы, домен/пошта қолжетімі жоқ, диск толған) және қалпына келтіруді (бэкаптар, баптауларды қайтару, деректерді орау) қамтиды.

Мысал: бір бөлімде «бәрі сәтті өтті», бірақ кейін белгілі болды: кей қызметкерлер ескі МФУ-ға басып шығарады. Олардың драйвері және басып шығару кезегі форматтары басқа. Бұл «жалпы баг» емес, бірақ адамдар үшін тоқтататын фактор.

Сәтсіздік 12: откат жоспары мен тоқтату критерийлері жоқ

Олай болса команда аварияға дейін іске қосуды тәуірлей береді: инциденттер саны өседі, сенім төмендейді, қолмен айналма жолдар пайда болады, олар кейін жою қиын болады.

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

Қабылдауды өлшенетін метрикалар бойынша жасаған дұрыс: «пайдаланушыларға ұнады» емес, «қолдау қызметі типтік сұрауларды орындайды», «күнделікті инциденттер X-тан аспайды», «критикалық операциялар Y минутта орындалады». Осылайша көшу лотереядан басқарылатын жобаға айналады.

Практикадағы тұзақтар — уақытында ескерілмейтіндер

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

Тұзақ 1: негізгі эксперт жұмыстан кетеді де, жоба «көрмейтін» болады

Бір адам интеграциялар мен құқықтарды, желідегі проблемаларды және неліктен кейбір пайдаланушылар регламент бойынша жұмыс істемейтінін білуі мүмкін. Егер білімдер жазылмаса, әрбір доработка тергеуге айналады.

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

Тұзақ 2: пилот сәтті өтті, бірақ масштаб желі мен сақтауға ұсады

20 адамдық пилот жақсы көрінуі мүмкін, ал 500 адамға өткенде каналдар «батып», сақтау жүктемесі өсіп, бэкап терезелері тым ұзақ болады. Бұл филиалдары бар және қашықтағы нүктелері бар компанияларда әсіресе байқалады.

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

Тұзақ 3: көлеңкелі ИТ және алғашқы 2 аптадағы қолдаудың жиналуы

Егер пайдаланушылар «қазір қалай дұрыс жасауды» түсінбесе, олар айналма жол табады: жеке мессенджерлер, бұлттар, флешкалар. Қолдау дайын болмаса, бірдей сұрақтардың ағымы уақытты жұтып, бәрін жүйкеге салады.

Бастапқы кезеңге қарапайым шаралар көмектеседі: 10–14 күнге бірінші сызықты күшейтіңіз және оларға дайын жауаптар беріңіз; кері байланыс арналары жасаңыз және қайталанатын проблемаларды тіркеңіз; ережелер туралы келісіңіз (не тыйым, не рұқсат, немен алмастырамыз); бөлімдерде әріптестерге жергілікті көмек көрсететін «чемпиондар» тағайындаңыз.

Қысқа чеклист: іске қоспас бұрын және іске асыру алдындағы тексеру

Open source-қа көшу қателері көбінесе оқиғалардан кейін ғана еске түседі. Өрт сөндірмеу үшін жоба жоспарына қысқа чеклист салыңыз да, әр статус сайын оралыңыз.

Іске қоспас бұрын

Ең алдымен жобаның мақсаты мен шекаралары бар екеніне көз жеткізіңіз. Одан басқа көшу тез шексіз қайта өңдеуге айналады.

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

Жылдам дайындық тесті: 2–3 қызметкерге ең жиі кездесетін бес тапсырманы (пошта, құжаттар, басып шығару, қолжетімдіктер, бірлесіп жұмыс) орындап, қай жерде тұрып қалғандарын жазуды сұраңыз.

Іске қоспас бұрынғы финал

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

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

Егер көшу жұмыс станциялары мен серверлерге әсер етсе (мысалы, мемлекеттік орган немесе банк), ИБ және эксплуатациямен алдын ала жұмыс терезелерін және алғашқы 2–4 аптадағы қолдау форматын келісіңіз.

Мысал сценарий: бөлімді хаоссыз open source-қа көшіру

200 қызметкері бар компания офис қосымшалары мен кей серверлерді open source-қа ауыстыруды шешеді. Мақсат: вендорға тәуелділікті азайту және адамдар мен процестер дайын болмай қалауының алдын алу.

Пилотты 20–30 қолданушыда жасаған жөн, бірақ кездейсоқ емес. Бухгалтериядан, сату, HR, заң бөлімі және техподдержкадан 3–5 адамнан алу керек. 1–2 белсенді қолданушы мен 1–2 скептикті қосыңыз. Пилот шынайы жұмысты көрсетіп, «идеал жағдайлардан» болмауы тиіс.

Пилот үшін көшу кезінде жиі бұзылатын 5–7 тапсырманы таңдаңыз: сырттық контрагенттермен бірлесіп құжат өңдеу; шаблондар мен басып шығару (келісімшарттар, шоттар, қол қою, сканерлеу); пошта мен күнтізбе; формулалары бар кестелер және 1С немесе ERP-ден деректі импорттау; файлдық папкалар мен құқықтарға қол жеткізу.

Өту кезеңі әдетте 2–4 апта алады: ескі және жаңа ортада параллельді жұмыс, жаңа құжаттар үшін нақты мерзім, күнделікті «қолдау терезесі» және жылдам сұрақтар үшін арна. Серверлік бөлікте пилот контур қайда болатынын алдын ала анықтаңыз (көп жағдайда бөлек түйінде), сонда продқа қауіп төнбейді.

Сәттілікті сезім бойынша емес, цифрлармен өлшеңіз. 30 күннен кейін:

• пилот тобының 70–80%-ы негізгі тапсырмаларды айналма жолсыз орындап жатыр
• типтік сұрауларды шешу уақыты өсіп кеткен жоқ
• деректер жоғалту және критикалық ақаулар жоқ

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

Келесі қадамдар: қалай миграцияны бастап, шаршаудың алдын алу

Срывтан басты қорғаныс — батырма емес, айқын жұмыс ырғағы. Егер open source-қа көшу кезінде типтік қателерді көріп отырсаңыз, оларды жауаптылар, мерзімдер және тоқтату ережелері бар қысқа жоспарға аударыңыз.

Кішкентай жұмыс тобы жинаңыз: IT, қауіпсіздік, бизнестен өкіл және 1–2 белсенді қолданушы. Мақсаттарды тіркеңіз (нені өзгертеміз), шектеулерді (мерзімдер, критикалық қосымшалар, реттеуші талаптар) және табыс критерийлерін (мысалы, айналма жолсыз орындалатын тапсырмалар үлесі).

Содан кейін қысқа итерациялармен әрекет етіңіз:

• инвентаризация: құрылғылар, ОС, негізгі қосымшалар, интеграциялар, құжат түрлері және шаблондар
• 2–4 аптаға пилот: тәуекелі басқарылатын бір бөлім немесе рөл
• оқыту: 30–60 минуттық мини-сессиялар және ең жиі әрекеттерге арналған еске салғыштар
• іске қосудың алғашқы 10–14 күні үшін қолдауды күшейту: бір арна және жылдам жауаптар
• откат жоспары және қалпына келтіру жаттығуы пилотқа дейін

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

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

Егер серверлік бөлік, жұмыс орындары мен енгізуде көмек қажет болса, жүйелік интеграторды қосу орынды. GSE.kz (gse.kz), мысалы, Қазақстанда ПК, жұмыс станциялары мен серверлерді өндіреді және пилот кезеңінде және ауысу алғашқы апталарында ел бойынша сервис желісі арқылы 24/7 сүйемелдеу ұсынады, бұл әсіресе пайдалы болады.