Який найкращий час для планування регулярних оновлень на сервері внутрішнього виробництва?

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

Очевидна відповідь на моє запитання - «вночі, коли користувачі вдома». Але "ніч" - це тривалий проміжок часу. Чи варто починати рано ввечері, щоб, можливо, рано назвати проблеми з оновленням і бути готовим до відкату? Або краще починати рано вранці і використовувати перших користувачів як «морських свинок», щоб швидше викликати проблеми? Або посеред ночі, коли концентрація того, хто наглядає за оновленням, досить низька, але гарантується відсутність ручок відкритих файлів у деяких пізніх працюючих користувачів?

Чи є якісь наукові роботи на цю тему?

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

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

IMHO, ваші "перші користувачі" не повинні бути морськими свинками. Отримати тестування користувачів, які в основному перевіряють виробництво, ваші зміни - це не дуже добре. Це руйнує впевненість кінцевих користувачів, і несподівані результати можуть зіпсувати виробництво, а це означає, що вам не тільки доведеться скасовувати зміни, а й відмовляти від будь-яких «збитків», які зміни можуть спричинити.

Я не знаю жодної дослідницької роботи, але погляньте на будь-яку структуру управління ІТ-сервісом (ITSM), наприклад ITIL, ви знайдете безліч стандартів та найкращих практик щодо управління випуском програмного забезпечення. Всі системи різні, тому залежить ступінь кількості практик, які ви застосовуєте, та їх формальність. Стандарти ITSM мають на увазі великі системи.

Це повністю залежить від характеру бізнесу. Деякі відділення працюють 9-5 п’ять днів на тиждень. Інші підприємства працюють 24 години на день, 365 днів на рік. Інші фактори, такі як наявність персоналу та наявність ресурсів, відіграють значну роль. Жоден дослідницький документ не міг би всебічно охопити всі можливі розклади чи події.

Зрештою, керівництво компанії або відділу узгоджено з ІТ-менеджментом має визначити, що найкраще.

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

Зрештою, у камені нічого не травиться. Якщо процес не працює, то внесіть корективи. Ваша гнучкість та адаптованість будуть оцінені.

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

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

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

У моєму випадку ми встановлюємо оновлення о 4 ранку, щоб уникнути впливу на будь-яких користувачів, навіть тих, хто працює трохи пізно.

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

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

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