Досягнення нульового простою

Я намагаюся досягти нульового простою, тому я можу менше розгортатись у неробочий час і більше у «повільніші» години - або будь-коли теоретично.

Моя поточна настройка, дещо спрощена:

• Веб-сервер A (.NET додаток)
• Веб-сервер B (додаток .NET)
• Сервер баз даних (SQL Server)

Мій поточний процес розгортання:

1. "Зупиніть" сайти як на веб-сервері A, так і на B
2. Оновіть схему бази даних для версії розгорнутої програми
3. Оновлення веб-сервера A
4. Оновіть веб-сервер B
5. Поверніть все до Інтернету

Поточна проблема

Це призводить до невеликої кількості простоїв щомісяця - близько 30 хвилин. Я роблю це в неробочий час, тому це не є величезною проблемою - але це те, від чого я хотів би піти.

Також - реально повернутися "назад" немає. Як правило, я не створюю сценарії відкату БД - лише сценарії оновлення.

Використання балансира навантаження

Я хотів би мати можливість оновити один веб-сервер одночасно. Візьміть веб-сервер A з балансира навантаження, оновіть його, поставте його назад в Інтернеті, а потім повторіть для веб-сервера B.

Проблема - база даних. Кожну версію мого програмного забезпечення потрібно виконати проти іншої версії бази даних, тому я начебто "застряг".

Можливе рішення

Поточним рішенням, яке я розглядаю, є прийняття таких правил:

• Ніколи не видаляйте таблицю бази даних.
• Ніколи не видаляйте стовпчик бази даних.
• Ніколи не перейменуйте стовпчик бази даних.
• Ніколи не упорядковуйте стовпчик.
• Кожну збережену процедуру необхідно доопрацювати.
  • Значення - "spFindAllThings" стане "spFindAllThings_2", коли воно буде відредаговано.
  • Потім він стає "spFindAllThings_3", коли його знову редагують.
  • Це ж правило стосується і поглядів.

Хоча це здається трохи екстремальним - я думаю, що це вирішує проблему. Кожна версія програми буде вражати БД нерозривним чином. Код очікує певних результатів від переглядів / збережених процедур - і це зберігає цей "контракт" дійсним. Проблема в тому, що вона просто просочується неохайно. Я знаю, що я можу очистити старі збережені процедури після того, як додаток буде розгорнуто на деякий час, але він просто забруднений. Також - це залежить від усіх розробників, які дотримуються цього правила, що в основному відбудеться, але я думаю, хтось помилиться.

Нарешті - моє запитання

• Це неохайно чи хакі?
• Хтось ще робить це так?
• Як інші люди вирішують цю проблему?

Це дуже прагматичний підхід до оновлення програмного забезпечення, що підтримується базами даних. Це було описано Мартіном Фаулером та Прамодом Садалажем у 2003 році та згодом написано у Refactoring Databases: Evolutionary Design Database Design .

Я бачу, що ви маєте на увазі, коли ви говорите, що це здається неохайним, але коли це робиться навмисно і заздалегідь, і витрачаючи час на рефакторинг невикористаних структур із бази коду та бази даних, коли вони, очевидно, більше не використовуються, це набагато надійніше, ніж більш прості рішення, засновані на сценаріях оновлення та відкату.

"Нульовий простой" - лише одна з багатьох можливих причин такого підходу. Таким чином, зберігаючи сумісність моделей даних, ви допомагаєте вирішувати безліч різних проблем:

• якщо у вашій базі даних багато програмних пакетів, вам не доведеться перевіряти їх, чи впливає на них зміна схеми (у великих організаціях, що мають декілька команд, що пишуть програми, які отримують доступ до однієї бази даних, зміни схеми можуть стати дуже важкими)

• якщо потрібно, ви можете перевірити старішу версію однієї зі своїх програм, і вона, швидше за все, запустить нову базу даних (доки ви не очікуєте, що стара програма буде обробляти будь-які нові колонки правильно)

• імпорт / експорт архівованих даних у поточну версію бази даних набагато простіше

Ось додаткове правило для вашого списку

• кожен новий стовпець повинен бути або NULLable, або надавати значуще значення за замовчуванням

(це гарантує, що навіть старші програми, які не знають нових стовпців, нічого не зламають, коли створюють нові записи у вашій базі даних).

Звичайно, у цього підходу є один реальний недолік: якість вашої моделі даних може погіршитися з часом. І якщо ви маєте повний контроль над усіма програмами, що мають доступ до вашої бази даних, і ви можете легко переробляти всі ці програми, коли ви, наприклад, збираєтесь перейменовувати стовпець, тоді ви можете подумати про рефакторинг речей більш чистим способом.

Він різниться в залежності від розгортання до іншого.

Звичайно, ви ніколи не можете видалити таблицю або стовпець. Ви ніколи не можете змінити нічого, що порушило б сумісність інтерфейсу. Ви завжди можете додати шар абстракції. Але тоді вам доведеться виконати цю абстракцію та версію версії.

Питання, яке вам потрібно задати собі, чи змінює кожен випуск схеми таким чином, щоб вона не була сумісною назад?

Якщо дуже мало випусків змінюють схему таким чином, то проблема з базою даних відключена. Просто виконайте розгортання серверів додатків.

Дві речі, які, як я бачив, найбільше допомагають із мінімальним простоєм:

1. Прагніть до зворотної сумісності - принаймні в межах одного випуску. Ви не завжди цього досягнете, але я можу покластися на те, що ви можете досягти цього на 90% або більше ваших релізів, особливо якщо кожен реліз невеликий.
2. Майте сценарій бази даних до випуску та після випуску. Це дозволяє обробляти переймена або зміни інтерфейсу, створюючи новий об’єкт до розгортання коду додатка, а потім скидати старий після розгортання коду програми. Якщо ви додасте новий стовпчик, що не зводиться нанівець, ви можете додати його як нульовий у своєму сценарії попереднього випуску із тригером, який заповнює значення за замовчуванням. Потім у своєму релізі можна скинути курок.

Сподіваємось, решту ваших пристроїв можна зберегти для вікон технічного обслуговування.

Інші ідеї, які можуть допомогти впоратися з кількома робочими помилками, які потребують простою:

• Чи можете ви створити зворотну сумісність у своєму коді? Наприклад, чи може ваш код підтримувати кілька типів наборів результатів? Якщо вам потрібно змінити стовпець з int на double, код вашого додатка може прочитати його як рядок і проаналізувати його. Вигляд хакі, але якщо це тимчасовий код, щоб пройти себе через процес випуску, це може бути не кінець світу.
• Збережені процедури можуть допомогти ізолювати ваш додаток від змін схеми. Це може зайти лише так далеко, але трохи допомагає.

Ви потенційно могли б зробити це так за трохи додаткових зусиль.

1. Резервне копіювання бази даних шляхом експорту
2. Імпортуйте резервну копію, але перейменуйте її з версією випуску, наприклад, myDb_2_1
3. Виконати випуск бази даних на myDB_2_1
4. "Зупиніть" пул додатків на веб-сервері A або вийміть його з балансира навантаження
5. Оновіть веб-сервер A, запустіть тести впровадження після публікації та, якщо потрібно, відкат
6. Сесія закриває веб-сервер B і повертає веб-сервер A назад у цикл
7. Оновіть веб-сервер B, а потім знову поставте в балансир завантаження

Звичайно, для веб-оновлень потрібні нові записи конфігурації для вказівки на нову схему Db. Річ у тому, що якщо ви робите релізи раз на місяць, і це невелика команда, скільки змін у БД ви насправді робите, які не сумісні назад? Якщо ви можете контролювати це, тестуючи, ви можете піти на отримання автоматизованого розгортання без простою часу, а може, в гіршому випадку, лише на 5 хвилин простою.