Сайтты техникалық қолдау шарты бизнес сайттың тұрақты жұмысын және қателер, іркілістер мен өзгерістер болған жағдайға арналған түсінікті ережелерді қалаған кезде қажет. Шартсыз қолдау тез арада шексіз шұғыл өтініштерге, кім кінәлі және төлемге нақты не кіретіні туралы дауларға айналады.
Жақсы шарт үш нәрсені бекітеді. Сіз нақты нені қолдайсыз. Инциденттер мен өзгерістермен қалай жұмыс істейсіз. Және сервис сапасын мерзімдер мен коммуникация ережелері арқылы қалай өлшейсіз.
Шарт не үшін қажет және ол қандай міндеттерді шешеді
Шарт екі тарапты да қорғайды. Бизнес болжамдылыққа ие болады. Орындаушы міндеттердің түсінікті аясын және келісу тәртібін алады.
Әдетте шарт мынадай міндеттерді шешеді:
- жұмыс құрамын бекітеді: мониторинг, жаңартулар, резервтік көшірмелер, қателерді жою, ұсақ түзетулер, әкімшілендіру
- жұмыс форматын анықтайды: қайда жазу керек, міндеттерді кім қабылдайды, кім келіседі, эскалация қалай өтеді
- мерзімдер бойынша ережелерді белгілейді: реакция уақыты, шешу уақыты, қолдау қай сағаттарда жұмыс істейді
- багтар мен доработкаларды бөледі, бизнес жаңа функция сұрап, оны қате түзету ретінде жасайды деп күткенде дауды азайту үшін
- жауапкершілікті бекітеді: рұқсаттар, хостинг, домен, бөгде сервистер, контент пен келісімдер үшін кім жауапты
- тапсыру процесін сипаттайды: подрядчик ауысқанда не болады, рұқсаттарды, құжаттаманы және бастапқы материалдарды қалай тапсырады
Техқолдау кепілдік түзетулерден немен ерекшеленеді
Кепілдік түзетулер іске қосылғаннан кейінгі кезеңге қатысты және әзірлеу кінәсінен пайда болған қателерді жабады. Әдетте бұл — жасалып, келісілген нәрсенің дұрыс жұмысына кедергі келтіретін багтар.
Техникалық қолдау кеңірек жұмыс істейді. Ол кез келген тірі жүйеде пайда болатын тұрақты міндеттерді қамтиды:
- CMS, модульдер мен тәуелділіктерді жаңарту
- қолжетімділікті бақылау және іркілістерге реакция
- қателерден кейінгі қалпына келтіру, оның ішінде резервтік көшірмелерден
- бизнес сұрауы бойынша доработкалар мен өзгерістер
- қолдау аясына кірсе, инфрақұрылым мен интеграциялармен жұмыс
Сондықтан кепілдік пен қолдауды бір бұлыңғыр блокқа араластырмаған маңызды. Бұл режимдерді бөлмесеңіз, іске қосқаннан кейінгі бірінші аптада-ақ дау аласыз.
Шарт бизнеске қашан ерекше маңызды
Шарт әрқашан қажет, бірақ онсыз бизнес ақша мен уақытты жоғалтатын жағдайлар бар:
- сайт өтінімдер мен сатылым әкеледі — кез келген тоқтап қалу бірден табыс пен беделге соқтығады
- интеграциялар бар: төлемдер, CRM, телефония, онлайн-жазылу, жеткізу, аналитика — кез келген іркіліс түсінікті процесс пен жауаптыларды қажет етеді
- сайтпен әртүрлі адамдар жұмыс істейді: маркетинг, контент-команда, жарнама подрядчиктері — регламентсіз олар баптауларды оңай бұзады
- дербес деректер мен рұқсаттар бар: формалар, жеке кабинет, пайдаланушылар базасы — қауіпсіздік пен инцидент кезіндегі әрекет тәртібін алдын ала сипаттау қажет
- сайт үнемі өзгереді: акциялар, жаңа беттер, жаңа қызметтер — ережесіз қолдау тез хаосқа айналады
Шарт нашар жұмыс істейтін терминдер мен анықтамалар
Қолдау шарты көбіне сөзден сынады. Бір тарап инцидент дегеніміз — сайттың құлауы деп ойлайды. Екіншісі мессенджердегі кез келген өтінішті инцидент деп санайды. Сондықтан шарттың басында анықтамалар қажет.
Бекіткен дұрыс терминдердің ең аз жиынтығы:
- сайт дегеніміз не: домендер мен поддомендер, беттер мен функционалдық модульдер, админ-панель, формалар мен интеграциялар
- қандай орталарды қолдайсыз: production — нақты сайт, stage — тестілеу ортасы, dev — әзірлеу ортасы
- инцидент дегеніміз не: сайттың немесе негізгі функциялардың жұмысын бұзатын оқиға
- баг дегеніміз не: қадаммен қайталанатын, келісілген функционалдықтағы ақау
- доработка дегеніміз не: логиканы, интерфейсті немесе функцияларды өзгерту — бұл талаптардың өзгеруі, баг емес
- жаңарту дегеніміз не: CMS, модульдер мен кітапханаларды жоспарлы орнату
- сұрау, приоритет, реакция уақыты мен шешу уақыты дегеніміз не
Бұл анықтамалар шартты ауырлатпайды. Олар оны жұмысқа жарамды етеді. Терминдер сәйкес келгенде, қолдау тыныш әрі үнемі нақтылаусыз жүреді.
Сайт пен prod, stage, dev орталары деп нені санайды
Шартта «сайт» сөзі көбіне тым кең естіледі, сондықтан подрядчик пен тапсырыс беруші нені қолдау керектігін әртүрлі түсінеді. Сайт құрамын компоненттер жиынтығы ретінде жазыңыз: жария бөлік пен админ-панель, дерекқор, серверлік бөлік пен интеграциялар. Сонымен қатар өтінім формалары, жеке кабинет, каталог, себет пен төлем, аналитика мен хабарландыру сервистері. Поддомендер, көптілділік, мобильді нұсқа немесе PWA болса, оны да атап өткен жөн.
Әрі қарай орталарды бекітіңіз. Prod — сайт пайдаланушыларға қолжетімді жұмыс ортасы. Stage — релизден бұрынғы соңғы тексеру ортасы. Dev — әзірлеу ортасы. Шартта қандай орталар қолдауға кіретінін және подрядчик әрқайсысында нақты не істейтінін тікелей көрсету маңызды.
Тағы бір жиі дау көзі — инфрақұрылым. Сервер, домен, SSL-сертификат, CDN немесе пошта үшінші тұлғаларда болса, мұны белгілеңіз. Төлем, ұзарту мен рұқсаттар үшін кім жауапты және хостингті ауыстыру қажет болса, баптауларды кім жасайтынын көрсетіңіз.
Инцидент, баг, доработка, жаңарту дегеніміз не
Инцидент — бұл сайттың немесе оның бөлігінің жұмысына әсер ететін іркіліс: сайт ашылмайды, формалар жіберілмейді, төлем өтпейді, жеке кабинет бұзылады, интеграция құлайды. Инцидент SLA бойынша реакцияны қажет етеді, өйткені бизнес өтінімдерді, ақшаны немесе деректерді жоғалтады.
Баг — дұрыс пайдалану кезінде көрінетін, бар логикадағы қате. Келісілген мінез-құлыққа қатысты нені баг деп санайтынын бекіту маңызды. ТЖ-да және қабылдауда бұл мінез-құлық болмаса, дау дерлік сөзсіз.
Доработка — функционалдықты өзгерту немесе кеңейту: каталогқа жаңа сүзгі, жаңа есеп, жаңа хабарландыру түрі, админкадағы жаңа рөл. Доработка дерлік әрқашан бағалауды, мерзімдерді келісуді және бөлек қабылдауды қажет етеді.
Жаңарту — сайтты өзекті әрі қауіпсіз күйде ұстайтын жоспарлы жұмыс. Жаңарту жүйенің мінез-құлқын сақтайды, ал доработка мінез-құлықты өзгертеді. Бөгде сервистер пайдаланылса, ереже қосыңыз: бөгде жеткізушідегі іркіліс — бизнес үшін инцидент, бірақ әрқашан подрядчиктің жауапкершілігі емес.
Приоритеттер мен критикалық деңгейлер қалай бекітіледі
Приоритизация ережесінсіз қолдау шұғыл міндеттер кезегіне айналады. Принциптен бастаңыз: приоритет ақшаға, өтінімдерге және негізгі сценарийлерге әсерге байланысты. Екінші фактор — әсер еткен пайдаланушылар саны. Үшінші — айналып өту шешімінің болуы.
Бірнеше деңгейді бекіткен ыңғайлы: критикалық (сайт қолжетімсіз немесе негізгі функция жұмыс істемейді), жоғары (сценарий қатты бұзылады, бірақ сайт қолжетімді), орташа (ақау бар, бірақ бизнес шектеулермен жұмыс істейді), төмен (мәселе ыңғайлылыққа немесе сыртқы түрге әсер етеді, бірақ процесті бұғаттамайды).
Әрі қарай шарт приоритетті кім беретінін және оны қалай өзгертетінін айтуы тиіс. Уақытты қалай санайтыныңызды міндетті түрде көрсетіңіз: жұмыс сағаттары бойынша ма, әлде күнтізбе бойынша ма. Бизнеске 24/7 режимі қажет болса, оны болжамдауға болмайды — оны бөлек бекіту керек.
Жұмыс көлемі және тараптар жауапкершілігінің шекаралары
Қолдау шарты шекаралары болғанда ғана жұмыс істейді. Олар екі тарапты да қорғайды. Тапсырыс беруші не үшін төлейтінін және не алатынын түсінеді. Подрядчик нені тұрақты істеуі керектігін, ал нені бөлек жұмыс деп санайтынын түсінеді.
Стандартты сүйемелдеуге қандай жұмыстар кіретінін, ал қайсысы қосымша болатынын сипаттаңыз. Міндеттерді қою арналары мен форматын көрсетіңіз, жұмыс сағаттары мен шұғыл өтініш ережелерін бекітіңіз. Жауапкершілікті аймақтар бойынша бөліңіз: контент пен жариялаулар көбіне тапсырыс берушіде қалады, инфрақұрылым тапсырыс берушіде немесе подрядчикте болуы мүмкін, интеграциялар аралас аймақта.
Сайтты сүйемелдеуге әдетте не кіреді
Сүйемелдеу — тұрақты және реактивті жұмыстар жиынтығы. Оның мақсаты қарапайым: сайт тұрақты жұмыс істеп, қауіпсіз болып қалуы және хаоссыз дамуы тиіс. Әдетте бұған кіреді:
- қолжетімділікті мониторингтеу және іркілістерді жылдам талдау
- багтарды түзету және формалардың, беттердің, интеграциялардың жұмысын қалпына келтіру
- келісілген ережелер шеңберінде CMS пен модульдерді жаңарту
- қауіпсіздікті бақылау, резервтік көшірмелер және іркіліс кезінде қалпына келтіру
- ұсақ түзетулер: мәтіндер, баннерлер, байланыс деректері, беттегі блоктар, аналитика метрикалары
- CRM, төлем, жеткізу және пошта сервистерімен байланыстарды бақылау
Ақыр соңында есептілік. Қарапайым қолдаудың өзі із қалдыруы тиіс: подрядчик кезең ішінде орындалған міндеттер тізімін және ашық өтініштер мәртебесін береді.
Не кірмейді және қосымша міндеттер қалай рәсімделеді
Сүйемелдеуге кіретін жұмыстар тізімінің қасында не кірмейтінінің бөлек тізімі қажет. Әдетте бұл — өнімді немесе бизнес-логиканы өзгертетін барлығы: жаңа беттер мен бөлімдер, жаңа функционал мен интеграциялар, дизайнды қайта өңдеу, басқа стекке көшіру, сайтты контентпен толтыру, жарнама кабинеттерімен жұмыс.
Қосымша міндеттер дауға айналмауы үшін үш қадамнан тұратын қарапайым процесс жазыңыз. Тапсырыс беруші мақсатпен, сілтемемен және дайындық критерийімен келісілген арнаға міндет қояды. Орындаушы сұрауды жіктейді — баг па, доработка ма — және мерзім мен құн бойынша баға береді. Тапсырыс беруші растайды, содан кейін міндет жұмыс жоспарына түсіп, приоритет алады.
Шұғыл жоспардан тыс жұмыстар туралы ереже қосыңыз: шұғыл міндет тек бөлек келісуден кейін жүреді және басқа мөлшерлеме бойынша немесе басқа уақыт терезесінде есептелуі мүмкін.
Тапсырыс беруші міндеттері: рұқсаттар, контент, келісімдер
Қолдау әзірлеуден емес, рұқсаттың, жауаптылардың және келісу ережелерінің болмауынан сынады. Тапсырыс беруші тарапынан бір өнім иесін тағайындаңыз: ол жұмыстарды қабылдайды, приоритеттерді келіседі және релиздерге соңғы рұқсат береді.
Рұқсаттарды жазыңыз. Тапсырыс беруші админкаға, хостингке немесе серверге, доменге, поштаға, аналитикаға, репозиторийге және бөгде сервистерге қол жеткізу береді, тіркелгі деректерінің өзектілігі мен оларды беру тәртібі үшін жауап береді. Контентті кім дайындайтынын және оның дұрыстығы мен материалдарға құқықтары үшін кім жауапты екенін нақтылаңыз.
Келісу ережелерін жазыңыз: тапсырыс беруші макеттер, түзетулер мен релиздер бойынша жауапқа қанша уақыт береді және жауап болмаса не болады. Бөлек — тапсырыс беруші үшінші тарап жасайтын кез келген өзгеріс туралы хабарлайды, әйтпесе қолдау қараңғыда себеп іздеуге айналады.
SLA және инциденттер матрицасы: сервис деңгейін қалай жазу керек
SLA — сіз сайтқа қызмет көрсететін ережелер. Ол бір сұраққа жауап береді: қолдау қаншалықты жылдам әрекет етеді және нені норма деп санайды. SLA-сыз шарт сайтты «жалпы» қолдау уәдесіне ұқсайды. Бұл бизнес үшін де, орындаушы үшін де қауіпті.
SLA-ны жалпы сөзбен емес, өлшенетін параметрлермен бекіткен дұрыс: реакция уақыты, шешу уақыты және қалпына келтіру уақыты, приоритеттер, жұмыс сағаттары, жоспарлы жұмыс терезесі және орындауды өлшеу тәсілі. Сайт өтінім мен ақша әкелсе, SLA-ны бизнес-функциялармен байланыстырыңыз — өтінім формасы, себет, төлем және авторизация үшін бөлек жоғары приоритет.
Реакция уақыты, шешу уақыты, қалпына келтіру уақыты
Реакция уақыты — өтініштен бірінші жауапқа және міндетті жұмысқа алуға дейін қанша уақыт өтеді. Бұл инциденттің көрінгенінің және талдау басталғанының растамасы.
Шешу уақыты — себепті жойып, инцидентті жабу үшін қанша уақыт қажет. Бұған әзірлеу, тестілеу және шығару кіруі мүмкін, ол мәселе түріне және орталардың қолжетімділігіне байланысты.
Қалпына келтіру уақыты — мәселенің тамыры әлі қалса да, критикалық функцияның жұмысын қайтару үшін қанша уақыт қажет: уақытша айналып өту сценарийін қостыңыз, релизді қайтардыңыз, қайшы келетін модульді өшірдіңіз. Уақытты қалай санайтыныңызды және нені үзіліс деп санайтыныңызды сипаттау маңызды, мысалы рұқсат немесе тапсырыс беруші жауабын күту.
Инцидент приоритеттері және жоспарлы жұмыс терезесі
Приоритеттер матрицасы команда маңыздылық туралы таласпауы үшін, ал бизнес неге кейбір міндеттер бұрын жүретінін түсінуі үшін қажет. Әр деңгейге эмоцияны емес, критерийлерді байланыстырыңыз:
- критикалық: сайт қолжетімсіз, төлем немесе өтінім жіберу жұмыс істемейді, авторизация бұзылған, ағып кету немесе бұзу күдігі бар
- жоғары: қате пайдаланушылардың айтарлықтай бөлігіне әсер етеді, негізгі сценарий бұзылады, бірақ айналып өту жолы бар
- орташа: қате бар, бірақ ол сценарийді бұғаттамайды, бір блок дұрыс жұмыс істемейді
- төмен: ұсақ түзетулер, косметика, мәтінді нақтылау, жұмысқа әсер етпейтін жақсартулар
Жоспарлы жұмыс терезесін бекітіңіз — жаңартуларды шығаратын, профилактика жасайтын және бэкаптарды тексеретін уақыт, релиздер кездейсоқ сәттерде болмауы үшін. Және эскалация ережесін қосыңыз: приоритетті кім және қалай көтереді, шешімді кім қабылдайды.
SLA-ны қалай өлшеу және нені бұзушылық деп санау керек
Алдымен өлшем бірліктері туралы келісіңіз. Қолдаудың жұмыс сағаттарын, сағаттық белдеуді және мереке күндерін бекітіңіз, SLA жұмыстан тыс уақытта әрекет ете ме, соны көрсетіңіз. Есеп қандай оқиғадан басталатынын және нені растама деп санайтыныңызды сипаттаңыз — мысалы тикеттегі орындаушының жауабы міндет нөмірімен.
Таймерді тоқтату ережелерін алдын ала анықтаңыз: тапсырыс беруші рұқсат бермегенде, өзгерістерді растамағанда, қайталау деректерін бермегенде немесе сайтты қол жетімсіз сыртқы сервис бұзғанда. Нені нақты SLA бұзушылығы деп санайтыныңызды сипаттаңыз: реакция уақытынан немесе критикалық инциденттердің қалпына келтіру уақытынан асу, тек дұрыс рәсімделген өтінім кезінде.
Бақылау тәсілін қосыңыз: барлық өтініштер міндетті өрістері бар бірыңғай міндеттер тізімі арқылы жүреді — тақырып, сипаттама, қайталау қадамдары, скриншоттар немесе логтар, приоритет, орта, байланыстар. Сонда сіз SLA бойынша есеп құра аласыз және әлсіз тұстарды көресіз.
Рұқсаттар, қауіпсіздік және деректерді қорғау
Қолдау рұқсатсыз жұмыс істемейді. Бірақ ережесіз ашық рұқсат тәуекел туғызады. Шартта рұқсаттарды кім және қалай алатынын, кім сақтайтынын және оларды қалай қайтаратыныңызды сипаттаңыз. Қауіпсіздіктің ең аз шаралары кез келген айыппұлдан маңыздырақ, өйткені деректер мен беделді қорғайды.
Рұқсаттарды деңгейлерге бөліңіз: сервер, сайт админкасы, репозиторий, бөгде сервистер панельдері, аналитика мен пошта. Әр деңгейге рұқсат тұрақты ма, әлде сұрау бойынша қажет пе және беруді кім келіседі — соны көрсетіңіз. Деректермен жұмыс ережелерін бірден бекітіңіз: қолдау дерлік әрқашан өтінімдерді, формаларды және логтарды көреді, кейде дербес деректермен.
Серверге, админкаға, репозиторийге рұқсат регламенті
Рұқсат форматын сипаттаңыз. Жеке тіркелгілер ортақтан жақсы: олар бақылау мен әрекеттер журналын береді. Тапсырыс беруші рұқсаттарды нақты адамдарға немесе рөлдерге береді, ал рұқсаттар жұмыстан шыққанда немесе команда ауысқанда жабылады.
Қолдауды бастау үшін қандай рұқсаттар қажет екенін көрсетіңіз — әдетте хостинг немесе сервер, админ-панель және кодқа қатысты болса репозиторий. Репозиторий жоқ болса, бастапқы код қайда сақталатынын бекітіңіз. Орталар туралы ереже қосыңыз: ең дұрысы — тексеру үшін stage пайдаланасыз, тек содан кейін prod-қа релиз жасайсыз.
Деплойға кімнің құқығы бар екенін және релиз фактісін қалай бекітетіңізді анықтаңыз — мысалы тикетте күн мен өзгерістер тізімі бар жазба. Бұл инциденттер мен даулы жағдайларды талдауға көмектеседі.
Дербес деректермен және құпиялылықпен жұмыс
Қандай деректерді құпия деп санайтыныңызды анықтаңыз: коммерциялық құжаттар, рұқсаттар, логтар, клиент деректері, пайдаланушылар базасы, қаржы мәліметтері. Орындаушы оларды тек жұмысты орындау үшін, үшінші тұлғаларға бермей және жарияламай пайдаланатынын көрсетіңіз.
Сайт формалар, жеке кабинет немесе төлем арқылы дербес деректер жинаса, базалық ережелерді бекітіңіз: формалардың мазмұны мен келісім мәтіндері үшін кім жауапты, деректерді кім және қайда сақтайды, кімде рұқсат бар. Деректерді қаншалықты аз адам көрсе, тәуекел соншалықты төмен.
Логтармен және түсірулермен қалай жұмыс істейтіңізді сипаттаңыз: олар қашан қажет, қайда сақталады және қашан жойылады. Құпияларды беру үшін бір қауіпсіз арна таңдаңыз — мысалы құпиясөз менеджері — және мұндай деректерді сұрауға кімнің құқығы бар екенін жазыңыз.
Қауіпсіздік инциденті кезіндегі әрекеттер мен хабарлама
Нені қауіпсіздік инциденті деп санайтыныңызды сипаттаңыз: админканы бұзу, контентті ауыстыру, базаның ағуы, күдікті белсенділік, күтпеген жаңа әкімшілер, сайттан жаппай таратылым. Мұндай анықтамалар талассыз дұрыс жұмыс режимін қосуға көмектеседі.
Әрекет тәртібін бекітіңіз: өтінішті кім қабылдайды, бастапқы шараларды кім іске қосады — құпиясөздерді ауыстыру, токендерді қайтару, рұқсатты бұғаттау, қызмет көрсету режимін қосу, логтарды тексеру. Жария коммуникация туралы шешім әрқашан тапсырыс беруші аймағы, бірақ қолдау техникалық фактілерді бере алады.
Хабарлама мерзімдерін және эскалация тәртібін сипаттаңыз: инцидент критикалық болса кімге қоңырау шалу керек және қандай байланыстар жұмыстан тыс уақытта жұмыс істейді. Қорытынды бойынша қысқа есеп пайдалы: не болды, қашан басталды, не істедік, қандай деректерге әсер етуі мүмкін және қайталану ықтималдығын не азайтады.
Резервтік көшірмелер және апаттық қалпына келтіру
Резервтік көшірмелер мен қалпына келтіру жоспары екі тәуекелді жабады: деректерді жоғалту мен сайттың тоқтап қалуы. Бұл ережелерді жазбасаңыз, дау апат сәтінде басталады. Бизнес жұмыс күйіне жылдам оралуды күтеді, подрядчик тек код үшін жауап бердім деп санауы мүмкін. Шарт бұл шиеленісті алдын ала шешуі тиіс.
Екі қабатты бірден бөліңіз: деректердің резервтік көшірмелері және кодтың резервтік көшірмелері. Деректер әдетте күн сайын өзгереді, код — релиздер бойынша. Бұл қабаттар әртүрлі сценарийлермен сақталады және қалпына келтіріледі.
Бэкап жиілігі және сақтау мерзімдері
Бэкапқа нақты не түсетінін бекітіңіз: дерекқор, сайт файлдары, пайдаланушы жүктеулері, конфигурациялар мен негізгі баптаулар. Сайт бөгде сервистерді пайдаланса, олардың деректерін әрқашан сайт бэкабынан қалпына келтіруге болмайтынын белгілеңіз — онда бөлек экспорт саясаты қажет.
Жиілікті санаттар бойынша сипаттаңыз — дерекқор, файлдар мен медиа, конфигурациялар — «тұрақты жасаймыз» деген жалпы сөзбен емес, нақты режиммен. Сақтау мерзімдерін сипаттап, оларды бизнес тәуекелдеріне байланыстырыңыз: бухгалтерлік және заңды деректер үшін мерзім әдетте ұзақ, промо-сайт үшін — қысқа.
Сақтау орнын бекітіңіз: продтың жанындағы бір сервер диск ақауы немесе бұзу кезінде көп жағдайда құтқармайды. Және бэкапты тексеруді қосыңыз — тестілеу қалпына келтірусіз көшірме көбіне бос формальдылыққа айналады.
Қалпына келтіру тәртібі және тоқтап қалу жауапкершілігі
Қалпына келтіру әрқашан сценарий бойынша жүреді. Оны қарапайым қадамдармен сипаттаңыз:
- инцидентті кім және қандай арна арқылы тіркейді
- қалпына келтіру мен қайтару туралы шешімді кім қабылдайды
- қай қалпына келтіру нүктесіне қайтасыз
- қалпына келтіруден кейін жұмысты қалай тексересіз
- трафикті қайтару мен сайтты ашуға кім рұқсат береді
Тоқтап қалу жауапкершілігінің шекараларын жазыңыз: сайт хостинг, домен, сыртқы API, төлемдер немесе тапсырыс беруші қызметкерлерінің әрекеттерінен құлауы мүмкін. Келісілген қайтару кезінде деректерді жоғалту тәуекелін кім көтеретінін көрсетіңіз — бизнес кешегі көшірмеге жылдам қайтуды таңдаса, ол жаңа деректердің бір бөлігін жоғалтуды қабылдайды.
Нұсқаулықта не болуы керек және оны кім жаңартады
Шартқа қосымшалар қажет, әйтпесе ол декларация болып қалады. Бэкаптар мен қалпына келтіру бойынша апат сәтінде ашуға болатын қысқа нұсқаулық болғаны пайдалы. Онда ең азын бекітіңіз:
- резервтеу қажет жүйелер мен компоненттер тізімі
- бэкаптар қайда жатыр және оған қалай кіру керек, кімде рұқсат бар
- қалпына келтіру тәртібі қадаммен және сайтты тексеру үшін stage-ке қалай көтеру керек
- негізгі сценарийлерді тексеру: басты бет, формалар, төлем, жеке кабинет, админка
- тапсырыс беруші мен подрядчик тарапынан эскалация байланыстары
Құжат иесін анықтаңыз: релиздер мен инфрақұрылым өзгерістерінен кейін нұсқаулықты кім жаңартады. Жиі қателік — нұсқаулық екі айдан кейін ескіреді де, апат кезінде ешкім не қайда жатқанын түсінбейді.
Қызмет
Сайтыңызды техникалық қолдауға аламыз
SLA, мониторинг, бэкаптар және рұқсат регламенті бар түсінікті қолдауды баптаймыз. Инциденттерді, доработкаларды және жаңартуларды бөліп, міндеттер мен сағаттар бойынша ашық есеп береміз. Код, аккаунттар мен кілттер сізде қалады.
Доработкалар, жаңартулар және жұмыс көлемінің өзгеруі
Қолдау дерлік әрқашан дамуға өтеді. Бизнес жаңа блоктарды, интеграцияларды, жеке кабинетті, жаңа есептерді сұрайды. Шарт қолдау мен дамуды бөлмесе, команда ай сайынғы жұмысқа не кіретіні туралы таласа бастайды.
Принципті бекітіңіз: қолдау жұмысқа қабілеттілік пен қауіпсіздікті сақтайды, доработкалар функционалдықты өзгертеді немесе жаңасын қосады, жаңартулар екеуі де болуы мүмкін. Жұмыс көлемін қалай өзгертетіңізді сипаттаңыз: сұрауды кім бастайды, міндет қандай түрде қойылады, мерзім мен құн қалай бағаланады, кім келіседі әрі приоритет қояды, релиз бен тестілеу қалай жоспарланады.
Багты жаңа функционалдықтан қалай ажырату керек
Баг — келісілген мінез-құлықтан ауытқу. ТЖ-да, прототипте немесе қабылданған сайт нұсқасында болды, бірақ басқаша жұмыс істейді. Мысалы: форма өтінім жібереді, бірақ хат келмейді; батырма мобильді нұсқада басылмайды, бірақ басылуы керек.
Жаңа функционалдық — талаптардың өзгеруі. Бұрын мұндай сценарий болмаған, енді оның пайда болуын қалайсыз: жаңа төлем тәсілін қосу, жеке кабинет жасау, жаңа CRM қосу. Шартта шешім критерийлерін бекіткен ыңғайлы:
- жобаның бастапқы материалдарында қажетті мінез-құлықтың сипаттамасы бар ма — ТЖ, прототиптер, макеттер, растамасы бар хат алмасу
- бұл сценарий қабылдауда болды ма және өзгерістерге дейін продакшенде жұмыс істеді ме
- сыртқы шарттар өзгерді ме — провайдер API-ды ауыстырды, хостинг нұсқаларды жаңартты, браузерлер талаптарды өзгертті
- өзгерісті кім бастады — бизнес ережелерді өзгертсе, бұл дерлік әрқашан жаңа міндет
Change Request процесі: бағалау, келісу, приоритизация
Change Request — жұмыс көлемін өзгертудің бақыланатын тәсілі. Ол екі тарапты да қорғайды: бизнес мерзім мен баға бойынша ашықтық алады, команда — түсінікті приоритет пен қабылдау критерийлерін. Өтінімнің ең аз құрамы: міндет сипаттамасы мен мақсаты, беттер мен сценарийлерге сілтемелер, күтілетін нәтиже, бизнес үшін критикалық деңгей, шектеулер мен қабылдау критерийлері.
Әрі қарай келісу циклін бекітіңіз: сұрауды бірыңғай арнада тіркеу, бастапқы бағалау мен тәуелділіктерді тексеру, мерзім мен еңбек шығыны бағасы, төлем моделін таңдау, приоритетті келісу және релиз жоспары.
Бөлек приоритизация ережесін бекітіңіз. Инциденттер мен қауіпсіздік әдетте дамудан жоғары жүреді. Ақша мен өтінімге әсер ететін өзгерістер жоғары приоритет алады. Косметикалық түзетулер тұрақты релиздерге жоспарланады.
Өзгерістерді қабылдау, тестілеу және релиз
Түсінікті қабылдаусыз өзгерістер ілініп қалады: бизнес әлі дайын емес дейді, команда — жасалды дейді. Әдетте қарапайым схема жұмыс істейді: команда нәтижені тестілеу ортасында көрсетеді, тапсырыс беруші келісілген критерийлер бойынша тексеріп, ескертулерді бір жерде береді, команда түзетіп, көрсетуді қайталайды, қабылдаудан кейін өзгерістер келісілген терезеде продакшенге шығарылады.
Тестілеуде жауапкершілік аймақтарын бөліңіз. Команда техникалық бөлікті тексереді: верстка, формалар жұмысы, интеграциялар, базалық сценарийлер. Тапсырыс беруші бизнес-мағынаны тексереді: мәтіндер, бағалар, шарттар, заңды тұжырымдар және контенттің дұрыстығы.
Релиздің не қамтитынын жазыңыз: серверге деплой, жұмысқа қабілеттіліктің базалық тексерісі, тәуелділіктер мен нұсқаулықты жаңарту, егер өзгерістер админкаға әсер етсе. Және шұғыл релиздер мүмкін, бірақ терезе мен приоритетті бөлек келісуді талап ететінін көрсетіңіз.
Төлем, есептілік және қосымша шығындар
Қолдаудағы төлем қарапайым әрі өлшенетін болуы тиіс. Сонда сіз бюджетті жоспарлайсыз және нақты не жасалғаны туралы таласпайсыз. Шартта тұрақты қолдауды, даму жұмыстарын және сыртқы шығындарды бөлген жөн.
Команда нақты жұмыстарды қалай тіркейтінін бірден анықтаңыз: міндеттер тізімі қайда сақталады, қанша уақыт кетті, есепке не кірді және оны қаншалықты жиі аласыз. Ыңғайлы минимум — кезең ішіндегі міндеттер мен сағаттар бойынша есеп, қоса инциденттер мен релиздер бойынша мәртебе.
Төлем модельдері: жазылым, сағат пакеті, time and materials
Жазылым. Сіз кезеңге тіркелген сома төлеп, келісілген сервис деңгейі мен жұмыс көлемін аласыз. Модель болжамдылық маңызды әрі тұрақты міндеттер болғанда қолайлы. Шартта жазылымға не кіретінін нақты сипаттау керек.
Сағат пакеті. Сіз айға немесе тоқсанға белгілі бір қолдау сағаттарын сатып аласыз, команда оларды факті бойынша есептен шығарады. Пайдаланылмаған сағаттар ауыса ма, есептен шығарудың ең аз бірлігі қалай саналады және еңбек шығыны қалай расталады — соны жазу маңызды.
Time and materials. Сіз келісілген мөлшерлеме бойынша нақты еңбек шығыны бойынша төлейсіз. Модель көлемі белгісіз міндеттерге қолайлы: күрделі доработкалар, интеграциялар, миграциялар. Бизнес көбіне модельдерді біріктіреді: жазылым немесе сағат пакеті базалық қолдау мен SLA-ны жабады, ал ірі өзгерістер бөлек бағалаулармен жүреді.
Лицензиялар, хостинг, бөгде сервистер: кім төлейді
Сайтты қолдау үшін дерлік әрқашан инфрақұрылым мен сервистер шығынынан бөлек төлейді. Шартта міндетті шығындар тізімін атаңыз: домен мен DNS, хостинг немесе сервер, SSL-сертификаттар, пошта сервистері, резервтік көшіру, CDN, ақылы модульдер, аналитика мен таратылым сервистері, төлем шлюздері. Әр позицияда аккаунт иесі кім және кім төлейтінін көрсетіңіз.
Негізгі аккаунттар тапсырыс берушіге рәсімделгені қауіпсізірек, ал подрядчик берілген рұқсаттар бойынша жұмыс істейді. Шығындарды төлеу мен растау тәртібін, лимиттерді және бюджетті бөлек келісуді талап ететін қосымша шығынды нені санайтыныңызды жазыңыз.
Инфрақұрылым төлемі кешіктірілгенде не болатынын бекітіңіз: домен немесе хостинг төленбесе, сайт тоқтап қалуы мүмкін. Сервистерге қол жеткізуді үшінші тарап төленбегені үшін бұғаттаса, подрядчик тоқтап қалу үшін жауап бермейді.
Актілер мен есептер: қандай метрикалар мен мерзімділік
Актілер мен есептер қолдауды басқарылатын етеді. Әдетте оларды айына бір рет дайындайды; жиі релиздер кезінде аралық есептерді аптасына немесе екі аптада бір рет қосады. Жұмыстар бойынша есеп құрамы: міндеттер тізімі, жұмыс түрі, орындалу күні мен уақыты, нақты жұмсалған уақыт, нәтиже және растамаға сілтеме.
Статистика үшін статистика емес, шынымен көмектесетін метрикаларды сұраңыз:
- приоритеттер бойынша инциденттер саны
- әр критикалық инцидент бойынша реакция уақыты мен қалпына келтіру уақыты
- келісілген приоритеттер бойынша мерзімінде орындалған өтінімдер үлесі
- пакеттегі сағаттар қалдығы немесе time and materials моделі бойынша нақты сағаттар
- тәуекелдер мен техникалық қарыз тізімі: ескірген плагиндер, осалдықтар, өзекті емес бэкаптар, өнімділік мәселелері
Қабылдау нысанын жазыңыз: тапсырыс беруші тарапынан жұмыстарды кім және қандай мерзімде қабылдайды, нені қабылдау деп санайды — мысалы қол қойылған акт немесе келісілген мерзім ішінде ескертудің болмауы.
Бастапқы кодқа және доработка нәтижелеріне құқықтар
Кодқа және доработка нәтижелеріне құқықтар көбіне қол қою сәтінде емес, жоба өскенде мәселеге айналады — подрядчикті ауыстырғыңыз келгенде, ішкі әзірлеушіні тартқанда немесе өнімді сатқанда. Шарт үндемесе, әр тарап жағдайды өз пайдасына түсіндіреді.
Қолдау шартында үш нәрсені бөлу маңызды: сайтты әзірлеу кезінде нені алдыңыз (бастапқы код, макеттер, рұқсаттар), қолдау барысында не пайда болады (патчтар, жаңа модульдер, интеграциялар, құжаттама) және бөгде компоненттерге не қатысты (ақылы тақырыптар, кітапханалар, өз лицензиясы бар плагиндер). Бизнес үшін төленген доработка нәтижелерінің тапсырыс берушіге өтетінін жазу практикалық.
Доработкалар мен дизайн-материалдар кімге тиесілі
Бұл тармақты барынша нақты еткен жөн. Артефактілер тізімін беріңіз:
- бастапқы код пен скрипттер
- дизайн-файлдар мен прототиптер
- контент пен мәтіндер, егер оларды жұмыс шеңберінде жасаса
- құжаттама, нұсқаулықтар, схемалар, спецификациялар
- сіздің жобаңызға жасалған баптаулар мен конфигурациялар
Құқықтардың өту сәтін анықтаңыз — әдетте төлем мен қабылдаудан кейін. Төлем ай сайын болса, әр есепті кезең нәтижелеріне құқықтың акт қойылғаннан кейін өтуін бекіткен ыңғайлы. Жоба дербес деректерді қамтыса, подрядчик деректерге құқық алмайтынын және оларды қолдаудан тыс пайдалана алмайтынын бөлек бекітіңіз.
Репозиторийге рұқсат және артефактілерді тапсыру тәртібі
Репозиторий мен тапсыру артефактілері — сіздің сақтандыруыңыз. Шарт үш сұраққа жауап беруі тиіс: код қайда жатыр, кімде рұқсат бар және сіз нені аласыз. Тапсырыс беруші үшін практикалық нұсқа — оның аккаунтындағы репозиторий, ал подрядчик рөлдер бойынша рұқсат алады. Ортақ аккаунттарға тыйым салып, жеке тіркелгілерді пайдаланыңыз.
Репозиторийден бөлек сізге серверге және хостинг панеліне, CMS пен админкаға рұқсаттар, домендер мен DNS тізімі, бөгде сервистер тізімі, деплой мен қайтару нұсқаулығы, бэкаптан қалпына келтіру нұсқаулығы және орта айнымалылары бар файл қажет. Расторжение кезіндегі тапсыру мерзімдерін және тапсырыс беруші тарапынан тапсыруды кім қабылдайтынын көрсетіңіз.
Көшірмеге құқықты бекітіңіз: репозиторий тапсырыс берушіде болса да, подрядчик сұрау бойынша код пен құжаттама архивін шығаруға міндетті. Бұл форс-мажор кезінде көмектеседі және аудитті жеделдетеді.
Подрядчик ауысқанда үздіксіздік үшін нені қарастыру керек
Қолдау командасын ауыстыру әрқашан тоқтап қалу тәуекелін әкеледі. Қандай артефактілерді және қандай түрде тапсыратыныңызды сипаттаңыз: рұқсаттар, интеграциялар тізімі, орталар схемасы, деплой нұсқаулықтары, резервтік көшіру ережелері. Құжаттама жоқ болса, солай бекітіңіз — және оны қолдау барысында өзекті ету міндетін қосыңыз.
Рұқсаттарды тапсыру тәртібін бекітіңіз: тіркелгілерді кім жасайды, құқықтарды кім береді, құпиясөздер қалай ауысады, тапсыру фактісі қалай тіркеледі. Бұл рұқсаттар бар, бірақ жұмыс істемейтін жағдайдан аулақ болуға көмектеседі.
Өтпелі кезеңде қолдаудың қалай жалғасатынын сипаттаңыз. Жиі тәжірибе: қолданыстағы подрядчик тапсыру күніне дейін критикалық инциденттерді жабады және жаңа ірі доработкаларды алмайды, ал жаңа подрядчик диагностикаға қосылып, жауапкершілікті біртіндеп қабылдайды.
Шартты бұзу және қолдауды тапсыру жоспары
Бұзу көбіне дау-дамайдан емес, міндеттердің өзгеруінен болады: компания инфрақұрылымды ауыстырады, команданы қайта жинайды, басқа қолдау моделіне өтеді. Шарт қоштасуды басталу сияқты нақты сипаттауы тиіс.
Тапсыруды процестің бөлігі етіңіз. Кім бастайтынын, кім қабылдайтынын, қандай мерзімдер мен міндетті қадамдарды анықтаңыз. Бұл бөлімді жұмыс нәтижелеріне құқықтармен және репозиторийге рұқсатпен байланыстырыңыз — сонда тапсыру соңғы сәттегі келіссөз нысаны емес, техникалық рәсімге айналады.
Хабарлама мерзімдері және өтпелі кезең
Бұзу туралы хабарлама мерзімін көрсетіңіз. Ол екі тарапқа да қажет: тапсырыс беруші жаңа команда іздеуге уақыт алады, подрядчик — критикалық міндеттерді жабуға және тапсыруды дайындауға. Подрядчик өтпелі кезеңде қандай жұмыстарды орындайтынын сипаттаңыз: ағымдағы SLA бойынша инциденттерді өңдеу, жоспарлы жаңартулар тек келісім бойынша, жаңа командаға кеңес беру.
Шығудағы приоритизацияның қалай өзгеретінін нақтылаңыз. Әдетте өтпелі кезеңде бизнеске даму емес, тұрақтылық маңыздырақ, сондықтан шарт доработкаларды тоқтатып, прод-ортаны қолдауға шоғырлануға мүмкіндік беруі тиіс.
Подрядчиктің жүйелерге рұқсаты қашан тоқтайтынын жазыңыз. Подрядчик әлі тұрақтылық үшін жауап берсе, мұны лезде жасамаңыз, бірақ рұқсаттарды мерзімсіз де қалдырмаңыз — рұқсаттар өшетін немесе тек оқу режиміне ауысатын күнді бекітіңіз.
Рұқсаттарды, деректерді, құжаттаманы тапсыру чек-парағы
Шартқа тапсыру чек-парағы бар қосымша қосыңыз. Ол уақытты үнемдейді және маңыздыны ұмытып кету тәуекелін азайтады, үш қабатты жабады — рұқсаттар, деректер және құжаттама.
- рұқсаттар: сервер мен хостинг панелі, домен мен DNS, SSL-сертификаттар, CMS пен админ-панель, дерекқор, репозиторий мен міндеттер жүйесі, аналитика мен бөгде сервистер
- деректер: дерекқордың өзекті дамптары, сайт файлдары мен пайдаланушы жүктеулері, орталардың конфигурациялары, интеграциялар мен API кілттері тізімі, провайдерлер байланыстары
- құжаттама: архитектура мен prod, stage, dev орталарының сипаттамасы, деплой мен қайтару нұсқаулығы, бэкап кестесі мен қалпына келтіру сценарийі, критикалық модульдер мен ақау нүктелерінің сипаттамасы
Чек-парақта жауаптыларды және тапсыруды растау нысанын көрсету маңызды: тапсыру актісі, корпоративтік поштаға хат немесе міндеттер жүйесіндегі жазба. Сонда бизнесте түсінікті із қалады.
Аяқталмаған міндеттер мен төлемге не болады
Шарт бұзу сәтінде жұмыстағы міндеттермен не істеу керектігін алдын ала анықтауы тиіс. Оларды үш топқа бөліңіз: қолжетімділік пен негізгі функцияларға әсер ететін инциденттерді әдетте қалпына келтіруге дейін жеткізеді; жоспарлы жұмыстарды түсінікті нүктеде тоқтатып, мәртебесін, бастапқы кодын және түсініктемелерін тапсыруға болады; әлі басталмаған міндеттерді тоқтатылды деп тіркейді немесе жаңа подрядчикке береді.
Есеп ережелерін сипаттаңыз. Жазылым мен сағат пакеті үшін пайдаланылмаған сағаттар қалай саналатынын және ауысуға не болатынын көрсетіңіз. Time and materials үшін — подрядчик нақты орындалған жұмыстар бойынша есеппен және міндеттер тізімімен шот ұсынатынын.
Берешек болғанда рұқсаттарға не болатынын бекітіңіз. Ымыра көбіне былай құрылады: тапсырыс беруші критикалық инфрақұрылымға рұқсатты сақтайды, ал подрядчик берешек өтелгенше жаңа жұмыстарды тоқтата алады. Бұл қаржы дауынан сайттың тоқтап қалу тәуекелін азайтады.
