ShotGrid арқылы контент өндірісін басқару: статустарды баптау

Қайдан басталады продакшндағы тәртіпсіздік және ShotGrid қалай көмектеседі

Біртұтас жүйе жоқ кезде хаос қалай көрінеді

Тәртіпсіздік әдетте «жаман адамдардан» емес, ұдайы келісімдердің жоқтығынан басталады. Тапсырмалар чатта қалады, статустар продюсердің басында сақталады, дедлайндар кестеде, ал файлдар сервердегі «финал_нақты_соңғы_v7» тәрізді папкаларда жиналады.

Ортақ статустар мен ережелер болмаған кезде ең маңызды нәрселер ыдырайды: не дайын, не тексеруде екені түсініксіз болады, кім келесі екенін және қайда актуальды нұсқа жатқанын анықтау қиын. Нәтижесінде артық түзетулер, жұмыстың дубльденуі және «жоғалған» файлдар пайда болады — файл дұрыс жерде емес немесе аты басқа.

Тікелей ауыртпалық — хабарландырулар. Кесте жоспарды сақтай алады, бірақ адамдарға дәл қазір не істеу керектігін уақытында айта алмайды. Сондықтан тіпті жақсы жоспар да шексіз еске салулар мен қолмен бақылауға айналады.

ShotGrid бұл олқылықтарды қалай жабады

ShotGrid үш тіректі бір жерге жинауға көмектеседі: тапсырмалар, статустар және контекст (талқылаулар, версиялар, файлдар). Әдетте оны бірнеше топ бірдей пайдаланады: продакшен (жоспарлау және бақылау), креатив (версия тапсыру және комментарийлер), техотдел (пайплайн, шаблондар, интеграциялар).

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

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

ShotGrid‑тің негізгі ұғымдары қарапайым тілде

ShotGrid жоба журналындай жұмыс істейді: не істейміз, кім істейді, қандай күйде және материалдар қайда жатыр. Команда жүйедегі терминдерді бірдей түсінсе, аралық сұрақтар мен ручной нақтылықтар азаяды.

Көпшілікке қажетті минималды сөздік:

• Project: жоба, адамдарға, этаптарға және деректерге арналған жалпы контейнер.
• Asset: жасалатын және қайта пайдаланылатын объект (персонаж, локация, логотип, 3D‑модель).
• Shot: монтаж құрылымындағы нақты кадр немесе сахна.
• Task: Asset немесе Shot бойынша жұмыс бөлімі (моделдеу, риг, композ, саунд).
• Version: жұмыстың нәтижесі, оны қарап және салыстыруға болады (рендер, превью, плейбласт).
• Note: тапсырмаға, версияға немесе кадрға байланған пікір немесе ескерту.

Көбінесе Task пен Version шатастырылады. Task — «не істеу керек және кім жауапты» деген сұраққа жауап береді. Version — «қазіргі уақытта не шыққан» деген сұраққа жауап береді. Бір тапсырманың көптеген версиялары болуы мүмкін. Version‑да әдетте автор, күн және қысқа сипаттамасы болады.

Күнделікті жұмысқа ондаған өрістерді толтыру қажет емес. Әдетте атауы, статусы, орындаушысы, мерзімі, приоритеті және Asset/Shot пен соңғы Version‑ға екі байланыс жеткілікті. Қалған өрістер (бюджеттер, метрикалар, кастомды атрибуттар) команда нақты қай нәрсе жетіспейтінін түсінгеннен кейін қосқан жөн.

Дубликаттарды құюдан сақтану үшін атау ережелерін алдын ала келісіңіз. Мысалы: шоттарға бірыңғай формат (SC010_SH020), ассеттерге бірдей атаулар (CHAR_Anna, PROP_Cup) және «финал_ең_нақты» сияқты атауларға тыйым. Қарапайым тексеру: егер объектіні іздеу арқылы тез табуға болмайтын болса, атаулар «бұзылған» деген сөз.

Сіздің пайплайнға сәйкес статустарды жобалау

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

Жақсы ереже: статустар кезеңдерден аз болуы керек. Кезеңдер 15 болуы мүмкін, ал статустар 6–8 шамасында. Солайша жүйе кішкентай таңбалар жиынтығына айналмайды және әркім бағытталған күйде қалады.

Көбінесе төмендегі база жеткілікті:

• Не басталмаған (күтуде)
• Орындауда
• Тексеруде
• Түзету керек
• Дайын (қабылданған)

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

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

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

Рөлдер мен құқықтар: артық күрделіліксіз баптау

ShotGrid‑тегі құқықтарды адамдарға емес, ролдерге байланысты оңайырақ баптау керек. Осылайша қызметкерлер ауысқанда рольді өзгерту жеткілікті, жүйені қайта жинаудың қажеті жоқ.

3–6 ролден бастаңыз, олар продакшнда шынымен бар. Әдетте продюсер, супервайзер, артист және клиент жеткілікті. Егер мердігерлер болса, олар жеке роль болуы керек, тіпті сол жұмысты істесе де: айырмашылық көбінесе сенімділігі мен оларға қандай ақпарат көрсетуге болатынында.

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

Құқықтар хаосқа айналмауы үшін алдын ала бірнеше сұраққа жауап беріп, сол бойынша жүріңіз:

• Статусты кім өзгерте алады — тек супервайзер ме әлде артисттер де ме?
• Versions‑ты кім жасайды және ревьюға жариялайды?
• Барлығына жазатын кім, ал кім тек өз командасында жазады?
• Қай өрістер «ішкі» саналады (мысалы, кідірістер себептері) және сырттан жасырылуы керек пе?
• Қайсысы жою немесе қайта атау құқығына ие?

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

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

Хабарландырулар мен жазылулар: ештеңе жоғалмауы үшін

ShotGrid‑тегі хабарламалар бақылау үшін емес, жылдамдық үшін қажет. Дұрыс баптау маңызды нәрсе дереу жетсін, ал қалғаны жоба лентасында тыныш тұрсын.

Ең алдымен реакция талап ететін оқиғаларды анықтаңыз. Әдетте мынадай оқиғалар жеткілікті:

• тапсырма статусының өзгеруі (мысалы, «Орындауда» → «Тексеруде")
• упоминанием бірге келген жаңа комментарий
• жаңа версия жүктелуі
• тапсырма тағайындау немесе қайта тағайындау
• дедлайн өзгерісі

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

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

Мысал: художник жаңа версия жүктеп, статусын «Тексеруде» қойды. Супервайзерге хабарлама келеді, ол версияға комментарий қалдырып, статусты «Түзету» қояды. Орындаушы бұл туралы бірден көріп, жұмыс тоқтамайды.

Комментарийлердегі мінез ережелері қарапайым, бірақ сағаттарды үнемдейді. Бір хабарламада бір әрекет жазсын (не түзету керектігін немесе не растау керектігін), контекст қосыңыз (қай жерде қарау: версия, кадр, элемент), мерзім немесе приоритет қойыңыз, және упоминанияны тек жауап беруі тиіс адамдарға қолданңыз.

Тапсырмаларды сервердегі файлдарға байланыстыру: түсінікті схема

ShotGrid нақты көмектессін десеңіз, әр файлдың серверде айқын орны болуы керек, ал әр тапсырманың карточкасында «қайда актуальды версия жатқаны» туралы нақты жауап болуы тиіс. Егер бұл болмаса, адамдар «финал_нақты_финал_3» файлын мессенджер арқылы жіберіп, уақытын жоғалтады.

Барлық жобаларға біртекті папка шаблонынен бастаңыз. Ол монтаж, графика, дыбыс және 3D үшін бірдей болуы тиіс, тіпті кейбір папкалар белгілі жобада қолданылмаса да. Осылай қателер азаяды және іздеу жеңілдейді.

Команданы түсіндіру оңай схема мысалы:

• 01_Source (исходниктер: камера, аудио, референстер)
• 02_Work (тапсырмалар бойынша жұмыс файлдары)
• 03_Renders (рендерлер, превью, playblast‑тар)
• 04_Publish (қабылданған версиялар, әрі қарай беру үшін дайын)
• 05_Delivery (тапсырыс берушіге тапсырылатын финалдар)

Келесі маңызды қадам: нәтижені тапсырмаға «басында» емес, ShotGrid‑ке байланыстырыңыз. Тапсырма карточкасында әдетте мына үш нәрсе болсын: папкаға жол, ереже бойынша файл атауы және ағымдағы версия. Мысалы: Project/02_Work/Shot010/Comp, Shot010_comp_v012.nk, v012.

Папка ішінде не бар екенін әрдайым түсіну үшін бөлімдеу қарапайым болуы керек: исходниктер 01_Source‑та тұрады және өзгертілмейді; жұмыс файлдары тек 02_Work‑та; превьюлар мен тест рендерлер 03_Renders‑та; «жарияланған» деп есептелетіндер 04_Publish‑қа түседі. Клиент үшін финалдар 05_Delivery‑ға жіберіліп, жұмыс файлдарымен араластырылмауы тиіс.

«Бір ғана шындық көзі» ережесін қатаң жасаңыз: актуальды файлды чаттан немесе «соңғы хаттан» емес, ShotGrid‑тегі Published/Version (немесе сіздің «Ағымдағы файл» өрісіңіз) объектісінен қараңыз, онда жол мен версия нөмірі көрсетілген. Егер файл жарияланбаған немесе ShotGrid‑ке тіркелмеген болса, пайплайн үшін ол әлі жоқ деп есептелсін, файл серверде жатса да.

Нөлден бастап бір спринтта кезең‑кезеңімен баптау

Егер бір спринт (әдетте 1–2 апта) бөлсеңіз, ShotGrid‑ті бастапқы жұмыс жағдайына келтіруге болады — команда онсыз емес, дәл қазір онда жұмыс істей бастасын. Маңыздысы — тек ең қажетін жасау және оны тірі мысалда тексеру.

Спринт бойынша жоспар: бос жобадан пилотқа дейін

Алғашында каркасты құрып, сынақтар арқылы кеңейтіңіз.

Бірінші қадам — жоба жасау және жұмыс кезеңдерін келісу. Сосын қысқа статустар тізімі (мысалы: To Do, In Progress, Review, Approved, On Hold) жасап, кім қашан статус өзгертетінін келісіңіз.

Келесі — Asset және Shot үшін тапсырма шаблондары жасау. Әр объект үшін 6–10 типтік тапсырма 30 «қосымша» тапсырмадан гөрі тиімдірек. Шаблондар уақыт үнемдеп, ручной қателер санын азайтады.

Содан кейін ролдер мен жауаптыларды тағайындаңыз. Әр тапсырманың бір иесі болуы керек, «бәрі біршама жауапты» деген қағида болмауы тиіс. Басты оқиғаларға жазылымдарды дереу қосыңыз: тапсырма тағайындау, статустың Review‑ға өтуі, комментарийлер, ревьюдан кері қайтару.

Соңында сервердегі папка құрылымын және атау ережелерін бекітіңіз. Мысал: Project/Assets/Character/Name/Work және Project/Shots/Seq/Shot/Publish. Маңыздысы — ShotGrid бірдей жолдарға сілтеме жасасын, әркімнің жеке «қайда қойғаны» бойынша емес.

Негізгі баптау бойынша мини‑проект 1–2 күнге жүргізіңіз: бір Asset және бір Shot, бір правкалар циклімен.

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

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

Енгізуде жиі кездесетін қателер мен тұзақтар

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

Үдерісті тез бұзатын қателер

Көбіне процестің бұзылуына бірнеше типтік нәрсе себеп болады.

Статустар тым көп және олардың бір бөлігі бір нәрсені білдіреді. Мысалы, «Тексеруде», «Ревью күтіп тұр», «Лидтің аппрувы» дегендер тек атаулары бойынша ерекшеленіп, команда қайсын таңдау керек екенін жиі талқылайды.

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

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

Файлдар мен рендерлер әртүрлі жерлерде: біреуде диск, біреуде ортақ папка, біреуде бұлт. Тапсырмада айқын привязка жоқ болса, іздеу квестке айналады.

Атау және версиялау ережесі жоқ. Соның нәтижесінде «final_final_2.mov» файлын тапсырмаға, шотқа және нақты түзетке сәйкестендіру мүмкін емес.

Бір қарапайым мысал: художник превьюны ShotGrid‑ке жүктейді, бірақ исходниктерін өзінде қалдырады. Супервайзер «Түзету керек» қояды, бірақ қай версияны түзету керектігін анықтай алмайды, өйткені тапсырмада папкаға жол немесе біртұтас атау форматы көрсетілмеген.

Противоядие де қарапайым: бір типті объект үшін шектеулі статустар жиынтығы, 2–3 ролді айқын құқықтармен, тек тағайындау мен статус өзгерісіне арналған хабарламалар, біртекті сақтау схемасы (исходник қайда, превью қайда, финал қайда) және тапсырмаға міндетті привязка немесе жариялау. Негізгі тәртіп бекіген соң жүйені кеңейту қауіпсіз болады.

Жұмысқа шығамас бұрын тез чек‑лист

Командаға «қазір ShotGrid‑те жұмыс істейміз» деп айтпас бұрын қысқа бір тексеруден өткізіңіз. Ол 20–30 минут алады, бірақ іске қосқаннан кейінгі түзетулерге бірнеше күнді үнемдейді.

5 тексеру — 80% проблеманы табады

• Әр тапсырмаға иесі тағайындалған және мерзім нақты көрінеді. Иесіз немесе «қашан‑болса» дедлайндары бар тапсырмалар сәл бөгетке ұшырайды.
• Статустар әр бөлімде бірдей түсіндіріледі. Әртүрлі рольдерден 2–3 адамнан «In Progress», «Review», «Approved» дегеннің мағынасы неде екенін сұраңыз — жауаптар әртүрлі болса, атауларды немесе сипаттаманы нақтылау керек.
• Статус өзгергеннен кейін не болатыны айқын. Негізгі өтулерде (мысалы, «Ревьюға дайын») келесі кім, ол не істейді және қандай нәтиже қабылданған болып саналады екені түсінікті болуы тиіс.
• Файл жолы нақты жұмыс барысында ізделетін жерде көрінеді. Тапсырма карточкасын ашып тексеріңіз: папкаға жол, версия атауы немесе қажетті папкаға привязка бар ма және команда нақты солай материалдарды аша ма.
• Хабарламалар шудан алыс тұр. Бір тест жасаңыз: бір тапсырманың статусын өзгертіп, кімге хабарлама келгенін тексеріңіз. Егер «бүкіл студияға» хабарлама келсе, адамдар бәрін елемеуі мүмкін.

Тірі тест ең пайдалысы: бір типтік тапсырманы (мысалы, «шоттың рендері» немесе «макетті дайындау») алып, оны барлық статустардан өткізіп, әр қадам чатсыз түсінікті болуын қараңыз.

Мысал сценарий: шағын жоба бастан‑аяқ

Қысқа рекламалық роликті елестетейік: 10 шот, команда 6 адам (продюсер, супервайзер, 2 артист, композер, монтажер), мерзім 2 апта. ShotGrid‑тің пайдасы — бәріне бірдей көрінуінде: не жасалған, не тексеруде, қай жерде правкалар және қандай файлтар актуальды.

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

Бастауға болатын жиынтық, көбінесе әр бөлімде түсінікті:

• Not Started (не басталмаған)
• In Progress (орындауда)
• WIP Review (қаралып жатқан черновик)
• Client/Sup Review (супервайзер/клиент ревьюсы)
• Changes (түзетулер)
• Final (қабылданған)

Бір шотта қалай көрінеді: анимация артисті v001 версиясын жасап, оны WIP Review‑ға жібереді. Супервайзер версияға кадр бойынша комментарий қалдырып, Changes қояды және дәл не түзету керектігін белгілейді. Артист v002 шығарады, тізбек қайталанады. Шот қабылданғанда тапсырма Final‑ға өтеді, және композерге соңғы қабылданған версия алу айқын болады.

Жаңа адам 30 минутта жүйеге кірісуі үшін сервердегі қарапайым және бірдей құрылым маңызды. Бір жұмысшы нұсқа:

/PROJECT
  /shots
    /sh010
      /anim
        /work
        /publish
      /comp
        /work
        /publish
      /review

Ереже: /publish‑қа тек ShotGrid‑тегі версияға сәйкес файлдар ғана түссін (файл атауы мен версия нөмірі сәйкес келсін). /work қарапайым жобалау файлдарын сақтау үшін, бірақ олар команданы шатастырмауы тиіс.

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

Пилоттан кейінгі келесі қадамдар: үдерісті және инфрақұрылымды бекіту

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

Ережелерді бекіту және шиеленісті азайту

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

Бір беттік мини‑регламент жазу пайдалы. Ол мінсіз болуы шарт емес, тек түсінікті болу керек:

• кім қандай сәтте статус өзгерте алады
• версияларды қалай атаймыз (мысалы, shot010_comp_v003)
• жұмыс файлдары қайда, финалдар қайда
• тапсырма берілгенде қандай мәлімет міндетті жазылады (қай версия қарау керек, не тексеру)
• блокер болғанда не істеу (кімге хабарласамыз, қандай статус қоямыз)

Инфрақұрылмды қолдау арқылы үдерісті нығайтыңыз

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

Егер сізге on‑prem тәсілі маңызды болса (локальды сақтау, қауіпсіздік талаптары, үлкен сценалармен жұмыс), алдын ала келісіңіз: продакшн қайда сақталады, жұмыс станциялары қалай қосылады, қалай көшіру жасалады және қолжетімділікті кім бақылайды.

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