გადასვლა უსაფრთხოების სხვა Cognos წყაროზე

როდესაც საჭიროა არსებული Cognos გარემოს ხელახალი კონფიგურაცია უსაფრთხოების სხვა გარე წყაროს გამოყენებისთვის (მაგ. Active Directory, LDAP და ა.შ.), არსებობს რამდენიმე მიდგომა. მე მიყვარს მათი „კარგი, ცუდი და მახინჯი“. სანამ ამ კარგ, ცუდ და მახინჯ მიდგომებს შევისწავლით, მოდით შევხედოთ ზოგიერთ ჩვეულებრივ სცენარს, რომლებიც ტენდენციურად ახდენენ ავტორიზაციის სახელების სივრცის ცვლილებებს Cognos გარემოში.

საერთო ბიზნეს დრაივერები:

აპარატურის ან ოპერაციული სისტემის განახლება - BI ტექნიკის/ინფრასტრუქტურის მოდერნიზება შეიძლება იყოს ხშირი მამოძრავებელი. მიუხედავად იმისა, რომ დანარჩენი Cognos შეიძლება ჩემპიონივით იმუშაოს თქვენს დახვეწილ ახალ აპარატურაზე და თანამედროვე 64-ბიტიან ოპერაციულ სისტემაზე, წარმატებებს გისურვებთ მიახლოება თქვენი წვრილმანი მენეჯერის დაახლოებით 2005 წლის ვერსიაზე ამ ახალ პლატფორმაზე. წვდომის მენეჯერი (პირველად გამოვიდა სერია 7 -ით) არის პატივსაცემი დღეები წარსულიდან მრავალი Cognos მომხმარებლისთვის. ეს არის ერთადერთი მიზეზი იმისა, რომ ბევრი მომხმარებელი ინახავს Windows Server 2003 – ის ძველ ვერსიას. ეს არის ძველი პროგრამული უზრუნველყოფა. რაც უფრო მალე შეძლებთ მისგან შორს გადასვლას, მით უკეთესი.

განაცხადის სტანდარტიზაცია- ორგანიზაციები, რომელთაც სურთ გააძლიერონ ყველა მათი აპლიკაციის ავთენტიფიკაცია ერთი ცენტრალიზებული ადმინისტრაციული კორპორატიული დირექტორიის სერვერის წინააღმდეგ (მაგ. LDAP, AD).

შერწყმა და შენაძენები- კომპანია A ყიდულობს კომპანიას B და სჭირდება კომპანიის B's Cognos გარემო, რომ მიუთითოს კომპანიის A დირექტორიის სერვერზე, მათი არსებული BI შინაარსის ან კონფიგურაციის პრობლემების გარეშე.

კორპორატიული დივერსიები- ეს არის შერწყმის სცენარის საპირისპირო, კომპანიის ნაწილი გადავიდა საკუთარ ერთეულში და ახლა უნდა მიუთითოს არსებული BI გარემოს დაცვის ახალ წყაროზე.

რატომ შეიძლება სახელების სივრცის მიგრაცია იყოს ბინძური

Cognos გარემოს უსაფრთხოების ახალ წყაროს მითითება არ არის ისეთი მარტივი, როგორც ახალი მომხმარებლის სახელის დამატება ერთიდაიგივე მომხმარებლებით, ჯგუფებითა და როლებით, ძველი სახელების სივრცის და VOILA- ს გათიშვა! მათი შინაარსი. სინამდვილეში, თქვენ ხშირად შეგიძლიათ სისხლიანი არეულობით დაასრულოთ ხელები და აი, რატომ…

ყველა Cognos უსაფრთხოების პრინციპს (მომხმარებლებს, ჯგუფებს, როლებს) მითითებულია უნიკალური იდენტიფიკატორი, რომელსაც ეწოდება CAMID. მაშინაც კი, თუ ყველა სხვა ატრიბუტი თანაბარია, CAMID მომხმარებლისათვის არსებული ავტორიზაციის სახელების სივრცე არ იქნება იგივე CAMID იმ მომხმარებლისთვის ახალი სახელების სივრცე ამან შეიძლება გაანადგუროს არსებული Cognos გარემო. მაშინაც კი, თუ თქვენ მხოლოდ რამდენიმე Cognos მომხმარებელი გყავთ, თქვენ უნდა გააცნობიეროთ, რომ CAMID ცნობები არსებობს თქვენს კონტენტის მაღაზიის მრავალ ადგილას (და შეიძლება არსებობდეს თქვენი შინაარსის მაღაზიის გარეთაც კი ჩარჩო მოდელებში, ტრანსფორმატორების მოდელებში, TM1 პროგრამებში, კუბებში, დაგეგმვის პროგრამებში და ა. ).

ბევრი Cognos მომხმარებელი შეცდომით თვლის, რომ CAMID– ს ნამდვილად აქვს მნიშვნელობა მხოლოდ ჩემი ფოლდერის შინაარსი, მომხმარებლის პრეფერენციები და ა.შ. ეს არ შეიძლება იყოს ჭეშმარიტებისგან შორს. ეს არ არის მხოლოდ თქვენი მომხმარებლების რაოდენობის საკითხი, ეს არის Cognos ობიექტების რაოდენობა, რომელიც თქვენ უნდა გაინტერესებდეთ. კონტენტის მაღაზიაში არის 140 -ზე მეტი სხვადასხვა ტიპის Cognos ობიექტი, რომელთაგან ბევრს შეიძლება ჰქონდეს მრავალი CAMID მითითება.

მაგალითად:

1. არცთუ იშვიათია, რომ თქვენს შინაარსის მაღაზიის ერთ განრიგს ჰქონდეს მრავალი CAMID მითითება (განრიგის მფლობელის CAMID, მომხმარებლის CAMID გრაფიკი უნდა იყოს გაშვებული, როგორც თითოეული მომხმარებლის CAMID ან განაწილების სია, რომელსაც უნდა გაუგზავნოს ელექტრონული ფოსტის ანგარიში და ა.შ.).
2. Cognos– ის ყველა ობიექტს აქვს უსაფრთხოების პოლიტიკა, რომელიც განსაზღვრავს, თუ რომელ მომხმარებლებს შეუძლიათ წვდომა ობიექტზე (იფიქრეთ „ნებართვების ჩანართი“). Cognos Connection– ის საქაღალდეში გათიშული უსაფრთხოების ერთ პოლიტიკას აქვს CAMID მითითება თითოეული მომხმარებლისთვის, ჯგუფისათვის და როლისათვის, რომელიც მითითებულია ამ პოლიტიკაში.
3. ვიმედოვნებთ, რომ თქვენ მიგიღიათ აზრი - ეს სია გრძელდება და გრძელდება!

ეს არ არის იშვიათი შემთხვევა, როდესაც კონტენტის მაღაზია შეიცავს ათობით ათას CAMID მითითებას (და ჩვენ ვნახეთ რამდენიმე დიდი ასობით ათასი).

ახლა, გააკეთე მათემატიკა იმაზე, რაც არის თქვენი Cognos გარემო და ხედავთ, რომ თქვენ პოტენციურად გაქვთ საქმე CAMID ცნობების ლაშქართან. ეს შეიძლება იყოს კოშმარი! თქვენი ავტორიზაციის სახელის სივრცის გადართვამ (ან ხელახლა კონფიგურაციამ) შეიძლება დატოვოს ყველა ეს CAMID მითითება გადაუჭრელ მდგომარეობაში. ეს აუცილებლად იწვევს Cognos შინაარსსა და კონფიგურაციის პრობლემებს (მაგ. გრაფიკები, რომლებიც აღარ მუშაობს, შინაარსი, რომელიც აღარ არის დაცული ისე, როგორც თქვენ ფიქრობთ, პაკეტები ან კუბურები, რომლებიც აღარ ახორციელებენ მონაცემთა დონის უსაფრთხოებას, ჩემი საქაღალდის შინაარსისა და მომხმარებლის დაკარგვას) პრეფერენციები და სხვა).

Cognos სახელების სივრცის გადასვლის მეთოდები

ახლა, ვიცოდეთ, რომ Cognos გარემოს შეიძლება ჰქონდეს ათობით ათასი CAMID მითითება, რაც მოითხოვს ახალი CAMID მნიშვნელობის პოვნას, ასახვას და განახლებას ავტორიზაციის ახალ სახელში, მოდით განვიხილოთ კარგი, ცუდი და მახინჯი მიდგომები ამ პრობლემის გადასაჭრელად.

კარგი: სახელების სივრცის შეცვლა პერსონაზე

პირველი მეთოდი (სახელის სივრცის შეცვლა) იყენებს Motio's, პერსონა IQ პროდუქტი ამ მიდგომის გათვალისწინებით, თქვენი არსებული სახელების სივრცე „იცვლება“ სპეციალური პერსონალური სახელის სივრცით, რომელიც საშუალებას გაძლევთ ვირტუალიზოთ უსაფრთხოების ყველა პრინციპი, რომლებიც ექვემდებარება Cognos– ს. უსაფრთხოების არსებული პრინციპები გამოაშკარავდება Cognos– ს ზუსტად იგივე CAMID– ით, როგორც ადრე, მიუხედავად იმისა, რომ მათ შეიძლება ჰქონდეთ უსაფრთხოების ნებისმიერი სხვა წყარო (მაგ. Active Directory, LDAP ან თუნდაც პერსონა მონაცემთა ბაზა).

ამ მიდგომის ულამაზესი ნაწილი ის არის, რომ ის მოითხოვს ნულოვან ცვლილებებს თქვენს Cognos შინაარსში. ეს იმიტომ ხდება, რომ პერსონას შეუძლია შეინარჩუნოს CAMID– ის არსებული დირექტორების მაშინაც კი, როდესაც მათ ახალი წყარო უჭერს მხარს. ასე რომ ... ყველა იმ ათიათასობით CAMID მითითება თქვენს შინაარსის მაღაზიაში, გარე მოდელები და ისტორიული კუბურები? მათ შეუძლიათ დარჩნენ ზუსტად ისე, როგორც არიან. სამუშაო არ არის საჭირო.

ეს არის ყველაზე ნაკლებად სარისკო, ყველაზე დაბალი ზემოქმედების მიდგომა, რომელიც შეგიძლიათ გამოიყენოთ არსებული Cognos გარემოს უსაფრთხოების ერთი გარე წყაროდან მეორეზე გადასვლისთვის. ეს შეიძლება გაკეთდეს ერთ საათში Cognos– ის გათიშვის დაახლოებით 5 წუთის განმავლობაში (ერთადერთი Cognos downtime არის გადატვირთვა Cognos მას შემდეგ რაც დააკონფიგურირებთ Persona სახელების სივრცეს).

ცუდი: სახელების სივრცის მიგრაცია პერსონას გამოყენებით

თუ მარტივი, დაბალი რისკის მიდგომა უბრალოდ არ არის თქვენი ჭიქა ჩაი, მაშინ იქ is სხვა ვარიანტი.

პერსონა ასევე შეიძლება გამოყენებულ იქნას სახელთა სივრცის მიგრაციის შესასრულებლად.

ეს გულისხმობს მეორე ავტორიზაციის სახელის სივრცის დაყენებას თქვენს Cognos გარემოში, თქვენი არსებული უსაფრთხოების ყველა პრინციპის (ძველი სახელების ადგილიდან) შესაბამის პრინციპებზე ახალ სახელების სივრცეში, შემდეგ (აქ არის სახალისო ნაწილი), ყველა პოვნა, რუქა და განახლება ერთი CAMID მითითება, რომელიც არსებობს თქვენს Cognos გარემოში: თქვენი შინაარსის მაღაზია, ჩარჩო მოდელები, ტრანსფორმატორის მოდელები, ისტორიული კუბურები, TM1 პროგრამები, პროგრამების დაგეგმვა და ა.

ეს მიდგომა არის სტრესული და ინტენსიური, მაგრამ თუ თქვენ ხართ ისეთი სახის Cognos ადმინისტრატორი, რომელსაც სჭირდება ცოტაოდენი ადრენალინი, რომ თავი ცოცხლად იგრძნოს (და არ აწუხებს გვიან ღამით / დილით ადრე დარეკვა), მაშინ ალბათ… ამ არის ის ვარიანტი, რომელსაც ეძებ?

პერსონა შეიძლება გამოყენებულ იქნას ამ პროცესის ნაწილების ავტომატიზაციის დასახმარებლად. ის დაგეხმარებათ შექმნათ რუქა უსაფრთხოების ძველ პრინციპებსა და უსაფრთხოების ახალ პრინციპებს შორის, ავტომატიზირება მოახდინოთ უხეში ძალის „მოძებნეთ, გაანალიზეთ, განაახლოთ“ შინაარსი თქვენს შინაარსის მაღაზიაში და ა.შ. რისი პერსონალიზაციასაც შეუძლია ზოგიერთი ამოცანის ავტომატიზაცია აქ, ბევრად ამ მიდგომის მუშაობა მოიცავს "ხალხს და პროცესს" და არა რეალურ ტექნოლოგიას.

მაგალითად - ინფორმაციის ჩარჩო მენეჯერის ყველა მოდელზე, ყველა ტრანსფორმატორის მოდელზე, ყველა დაგეგმვა / TM1 პროგრამაზე, ყველა SDK პროგრამაზე, ვინც მათ ფლობს და მათი განახლებისა და გადანაწილების დაგეგმვა შეიძლება ბევრი სამუშაო იყოს. კოგნიზების გათიშვის კოორდინაცია თითოეული Cognos გარემოსთვის, რომლის გაკეთებაც გსურთ და ფანჯრების მოვლა, რომლის დროსაც თქვენ შეძლებთ მიგრაციის მცდელობას, შეიძლება შეიცავდეს დაგეგმარებას და Cognos– ს „დროის შემცირებას“. თქვენი მიგრაციის შემდგომი ეფექტური სატესტო გეგმის შემუშავება (და განხორციელება) ასევე შეიძლება საკმაოდ დათვი იყოს.

ისიც სავსებით ნორმალურია, რომ თქვენ მოგინდებათ ეს პროცესი ჯერ არაწარმოების პირობებში გააკეთოთ ადრე ცდილობს მას წარმოებაში.

მიუხედავად იმისა, რომ პერსონალური სახელების მიგრაცია მუშაობს (და ეს ბევრად უკეთესია, ვიდრე ქვემოთ მოყვანილი "მახინჯი" მიდგომა), ის უფრო ინვაზიური, სარისკოა, ბევრად მეტ პერსონალს მოიცავს და გაცილებით მეტ საათს იღებს, ვიდრე სახელის სივრცის შეცვლა. როგორც წესი, მიგრაცია უნდა განხორციელდეს "გამორთულ საათებში", როდესაც Cognos გარემო ჯერ კიდევ ონლაინშია, მაგრამ შეზღუდული ფორმით გამოიყენება საბოლოო მომხმარებლების მიერ.

Ugly: სახელობითი სივრცის მიგრაციის სერვისები

მახინჯი მეთოდი გულისხმობს მცდელობის არაშექმნიან მიდგომას ხელით მიგრაცია ერთი ავტორიზაციის სახელის ადგილიდან მეორეზე. ეს გულისხმობს მეორე ავტორიზაციის სახელის სივრცის თქვენს Cognos გარემოსთან დაკავშირებას, შემდეგ კი ცდილობს ხელით გადააადგილოს ან შექმნას არსებული Cognos შინაარსი და კონფიგურაცია.

მაგალითად, ამ მიდგომის გამოყენებით, Cognos ადმინისტრატორმა შეიძლება სცადოს:

1. ხელახლა შექმენით ჯგუფები და როლები ახალ სახელთა სივრცეში
2. ხელახლა შექმენით ის ჯგუფები და როლები ახალ სახელების სივრცეში
3. ხელით დააკოპირეთ ჩემი საქაღალდეების შინაარსი, მომხმარებლის პარამეტრები, პორტალის ჩანართები და ა.შ. თითოეული წყაროს ანგარიშიდან თითოეულ მიზნობრივ ანგარიშზე
4. იპოვეთ შინაარსის მაღაზიაში არსებული ყველა პოლიტიკა და განაახლეთ იგი ექვივალენტურ პრინციპებზე ახალი სახელების სივრცეში ზუსტად ისე, როგორც ეს მიუთითებდა ძველ სახელთა სივრცის პრინციპებზე
5. ხელახლა შექმენით ყველა გრაფიკი და შეავსეთ ისინი შესაბამისი სერთიფიკატებით, მიმღებებით და ა.
6. კონტენტის მაღაზიაში ყველა ობიექტის ყველა „მფლობელის“ და „კონტაქტის“ თვისებების გადაყენება
7. [კონტენტის მაღაზიაში დაახლოებით 40 სხვა რამ, რომელთა დავიწყებასაც აპირებთ]
8. შეაგროვეთ ყველა FM მოდელი ობიექტის ან მონაცემთა დონის უსაფრთხოებით:
   1. განაახლოთ თითოეული მოდელი შესაბამისად
   2. ხელახლა გამოაქვეყნეთ თითოეული მოდელი
   3. შეცვალეთ მოდელი თავდაპირველ ავტორს
9. მსგავსი სამუშაოები Transformer მოდელებისთვის, TM1 პროგრამებისთვის და დაგეგმვის პროგრამებისთვის, რომლებიც დაცულია ორიგინალური სახელების სივრცის წინააღმდეგ
10. [და მრავალი სხვა]

მიუხედავად იმისა, რომ ზოგიერთი Cognos მაზოხისტი შეიძლება ფარულად იღიმოდეს სიხარულით Cognos Connection– ში 400,000 XNUMX – ჯერ დაჭერის იდეაზე, ყველაზე გონიერი ხალხისთვის, ეს მიდგომა უკიდურესად დამღლელი, შრომატევადი და შეცდომებისკენ მიდრეკილია. ეს არ არის ამ მიდგომის ყველაზე დიდი პრობლემა.

ამ მიდგომის ყველაზე დიდი პრობლემა ის არის, რომ თითქმის ყოველთვის იწვევს არასრულ მიგრაციას.

ამ მიდგომის გამოყენებით თქვენ (მტკივნეულად) პოულობთ და ცდილობთ დაადგინოთ ის CAMID ცნობები, რომელთა შესახებაც იცით… მაგრამ თქვენ მიტოვებთ ყველა იმ CAMID მითითებას შესახებ არ ვიცი.

ერთხელ თქვენ ვფიქრობ თქვენ დაასრულეთ ეს მიდგომა, ხშირად არა ნამდვილად შესრულებულია.

თქვენ გაქვთ საგნები თქვენს შინაარსის მაღაზიაში, რომლებიც აღარ არის დაცული ისე, როგორც თქვენ ფიქრობთ ... თქვენ გაქვთ გრაფიკები, რომლებიც არ მუშაობს ისე, როგორც ადრე, თქვენ გაქვთ მონაცემები, რომლებიც აღარ არის დაცული თქვენი აზრით ეს არის და თქვენ შეიძლება გქონდეთ აუხსნელი შეცდომები გარკვეული ოპერაციებისთვის თითს ნამდვილად ვერ დაადებ.

მიზეზები, რის გამოც ცუდი და მახინჯი მიდგომები შეიძლება იყოს საშინელი:

• სახელების სივრცის ავტომატური მიგრაცია დიდ სტრესს აყენებს შინაარსის მენეჯერს. თქვენი შინაარსის მაღაზიის თითოეული ობიექტის შემოწმება და პოტენციური განახლება ხშირად შეიძლება გამოიწვიოს ათობით ათასი SDK ზარი Cognos– ზე (თითქმის ყველა გადის კონტენტის მენეჯერის მეშვეობით). ეს არანორმალური შეკითხვა, როგორც წესი, ზრდის მეხსიერების გამოყენებას / დატვირთვას და კონტენტის მენეჯერს აყენებს მიგრაციის დროს ჩავარდნის საფრთხეს. თუ თქვენ უკვე გაქვთ რაიმე სახის არასტაბილურობა თქვენს Cognos გარემოში, თქვენ უნდა შეგეშინდეთ ამ მიდგომის.
• სახელების სივრცის მიგრაცია საჭიროებს შესამჩნევი მოვლის ფანჯარას. Cognos უნდა იყოს მაღლა, მაგრამ თქვენ არ გინდათ რომ ადამიანებმა ცვლილებები შეიტანონ მიგრაციის პროცესში. ეს ჩვეულებრივ მოითხოვს სახელების სივრცის მიგრაციას, როდესაც სხვა არავინ მუშაობს, ვთქვათ პარასკევს საღამოს საღამოს 10 საათზე. არავის სურს პარასკევს საღამოს საღამოს 10 საათზე სტრესული პროექტის დაწყება. რომ აღარაფერი ვთქვათ, თქვენი გონებრივი შესაძლებლობები ალბათ არ არის საუკეთესო სამუშაო ღამეებსა და შაბათ -კვირას იმ პროექტზე აკეთებს მოითხოვს, რომ იყოთ მკვეთრი!
• მე აღვნიშნე სახელთა სივრცის მიგრაცია დროისა და შრომის ინტენსიურია. აქ არის ცოტა მეტი ამის შესახებ:
  • შინაარსის შედგენის პროცესი უნდა მოხდეს ზუსტად და მოითხოვს გუნდურ თანამშრომლობას და ბევრ საათს.
  • საჭიროა მრავალი მშრალი გაშვება, რათა შეამოწმოთ შეცდომები ან პრობლემები მიგრაციასთან დაკავშირებით. ტიპიური მიგრაცია სრულყოფილად არ მიდის პირველ ცდაზე. თქვენ ასევე დაგჭირდებათ თქვენი შინაარსის მაღაზიის მოქმედი სარეზერვო ასლი, რომლის აღდგენა შესაძლებელია ასეთ შემთხვევებში. ჩვენ ვნახეთ ბევრი ორგანიზაცია, რომელსაც არ აქვს კარგი სარეზერვო ასლი (ან აქვს სარეზერვო საშუალება, რომელიც მათ არ ესმით არასრული).
  • თქვენ უნდა ამოიცნოთ ყველაფერი გარეთ შინაარსის მაღაზია, რომელიც შეიძლება იყოს პოტენციურად ზემოქმედებული (ჩარჩო მოდელები, ტრანსფორმატორების მოდელები და ა.შ.). ეს ამოცანა შეიძლება მოიცავდეს კოორდინაციას მრავალ გუნდში (განსაკუთრებით დიდი საერთო BI გარემოში).
  • თქვენ გჭირდებათ კარგი სატესტო გეგმა, რომელიც მოიცავს წარმომადგენლობით ადამიანებს, რომლებსაც აქვთ სხვადასხვა ხარისხის წვდომა თქვენს Cognos შინაარსზე. აქ მთავარია გადაამოწმოთ მიგრაციის დასრულებიდან მალევე, რომ ყველაფერი სრულად არის მიგრირებული და ფუნქციონირებს ისე, როგორც თქვენ მოელით. როგორც წესი, არაპრაქტიკულია ყველაფრის გადამოწმება, ასე რომ თქვენ საბოლოოდ ამოწმებთ იმას, რისი იმედიც გაქვთ, რომ წარმომადგენლობითი ნიმუშებია.
• თქვენ უნდა გქონდეთ ბroad კოგნოსის გარემოს ცოდნა და მასზე დამოკიდებული საგნები. მაგალითად, ისტორიული კუბურები მორგებული ხედებით უნდა გადაკეთდეს, თუ მიდიხართ NSM მარშრუტზე.
• რა მოხდება, თუ თქვენ ან იმ კომპანიას, რომელსაც თქვენ აუთსორსინგი გაუკეთეთ სახელების სივრცის მიგრაცია, დაივიწყებთ რაღაცას, მაგალითად… SDK პროგრამებს? მას შემდეგ რაც შეცვლით გადამრთველს, ეს ნივთები შეწყვეტს მუშაობას, თუ ისინი სწორად არ განახლდება. გაქვთ თუ არა შესაბამისი შემოწმება, რომ ეს დაუყოვნებლივ შეამჩნიოთ, თუ რამდენიმე კვირა / თვე იქნება სიმპტომების გამოვლენამდე?
• თუ თქვენ გაიარეთ მრავალი Cognos განახლება, პოტენციურად შეგიძლიათ გქონდეთ თქვენს შინაარსის მაღაზიაში არსებული ობიექტები, რომლებიც არათანმიმდევრულ მდგომარეობაშია. თუ თქვენ არ მუშაობთ SDK– სთან, თქვენ ვერ დაინახავთ რომელი ობიექტებია ამ მდგომარეობაში.

რატომ არის სახელის სივრცის შეცვლა საუკეთესო ვარიანტი

ძირითადი რისკფაქტორები და შრომატევადი ნაბიჯები, რომლებიც ახლახან გამოვსახე, აღმოფხვრილია, როდესაც გამოიყენება პერსონალური სახელების სივრცის შეცვლის მეთოდი. სახელების სივრცის შეცვლის მიდგომის გამოყენებით, თქვენ გაქვთ 5 წუთი Cognos– ის გათიშვის დრო და არცერთი თქვენი შინაარსი არ უნდა შეიცვალოს. "კარგი" მეთოდი ჩემთვის მოწყვეტილ და მშრალ "უაზროდ" მეჩვენება. პარასკევის ღამეები დასასვენებლად არის განკუთვნილი და არ ხაზს უსვამს იმ ფაქტს, რომ თქვენი შინაარსის მენეჯერი უბრალოდ ჩამოვარდა სახელის სივრცის მიგრაციის შუაგულში.