Преди около година и половина се преместих в нова компания и започнах работа като техен DBA. Компанията преди това не е прилагала никакви корекции към бази данни на Oracle. Откакто съм тук, видях, че сигурността на ИТ системата става по-скоро фокусна точка и се подлага на по-високо ниво на контрол, което виждахме преди. Вместо да чакам директива, която да започне да прилага редовни корекции за сигурност за нашите бази данни на Oracle, реших да бъда проактивен. Ще дойде денят, когато трябва да започнем редовно да коригираме нашите бази данни на Oracle и бих искал да кажа, че вече го прилагаме.
Процесорът Apr2012 беше пуснат току-що миналата седмица и това е първият процесор, който ще приложим към нашите бази данни на Oracle. Преди да приложа първия CPU, малко се замислих как да приложим тази промяна в нашата корпоративна среда. Реших да споделя някои от тези промени, в случай че някой друг изпадне в подобна ситуация в бъдеще.
1. 3 D:Преди да започне каквото и да е корекция, политиката за корекции беше документирана, разпространена на ИТ персонала и ръководството и обсъдена. Този документ обсъжда на високо ниво необходимостта от редовни корекции за сигурност, кога ще излязат корекциите за сигурност и как ще бъдат приложени към нашите системи, за да се намали рискът за базата данни, приложението и крайните потребители.
2. Patch Timeline – Имам лукса да имам клонинг на нашата производствена база данни само за използване от DBA и никой друг. Моята хронология започва от там. В рамките на една седмица след пускането на процесора трябва да приложа процесора към моята DBA база данни и да разреша всички проблеми. След две седмици от пускането на процесора, трябва да приложа корекцията към нашите бази данни за разработка. В рамките на един месец след пускането на процесора трябва да приложа корекцията към базата данни Test and Stage. И накрая, в рамките на 6 седмици след пускането на процесора, трябва да приложим корекцията в производството. Това е само моята времева линия и това, което работи в нашата среда. Времевата ви линия може да е различна. Но е важно всички да разбират времевата линия и времевата линия да прави две привидно противоречиви неща – 1) да прилага корекцията бавно, така че всички проблеми с базата данни или приложението да бъдат подредени, преди да се пристъпи към следващата стъпка в времевата линия. След като пластирът влезе в производство, не трябва да има изненади и увереност, че пластирът няма да счупи нищо. 2) прилага пластира достатъчно бързо, така че дупките в сигурността да бъдат запушени в разумно време. В моята среда шест седмици до производство са достатъчно бавни, за да се уловят проблеми, но приблизително толкова бързо, колкото се чувстваме комфортно. Вашата среда може да има други времеви линии.
3. Регистрирайте го – твърдо смятам, че кръпките трябва да бъдат документирани в някакъв дневник на промените. С регистрационния файл трябва да можете да се върнете назад и да видите точно кога е приложена всяка корекция към всяка база данни. Това може да измине дълъг път при диагностицирането дали кръпка е отговорна за проблем. Ако получа талон, че дадена процедура получава грешки и проблемът е отбелязан за първи път на 1 май, тогава мога да погледна регистъра на промените. Ако приложих пластира на 30 април, тогава пластирът може да е въвел проблема. Но ако поставих пластира на 2 май и проблемът е съществувал ден по-рано, значи пластирът не е причината за проблема. Някои организации вече имат механизъм за контрол на промените и регистрационният файл на корекцията на Oracle трябва да се побере в тази структура.
4. Тест/Тест/Тест – Като DBA, ние сме длъжни да гарантираме, че промените, въведени в производството, имат висока степен на увереност, че приложението няма да се счупи. Жизнено важно е да тествате промените си и кръпките не се различават. Ако не преминете през времевата линия на кръпката, няма да имате достатъчно време за тестване и ако има проблем, който пластирът е въвел във вашата среда, би било самоубийство в кариерата, ако не сте тествали адекватно, преди да започнете производството.
5. Архивиране – Трябва да направите резервно копие на базата данни и началната директория на Oracle, която се пачове, преди да приложите корекцията. Никога не знаете дали ще трябва да се върнете към предишна точка преди корекцията в една или и двете области. От време на време трябва да тествате методологията за възстановяване или архивиране на пачове доста преди производството. Това тестване може да не е задължително да се прави веднъж на тримесечие, но трябва да се прави поне веднъж годишно.
Мисля, че тези за покриват основните мисли, които имах по темата. Ако имате въпроси/коментари, уведомете ме.
