Будь-які ідеї, як запустити обслуговування на сайті, який завжди використовується?


18

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

Ми намагалися зробити наш сайт постановки таким же схожим на виробничий майданчик, але ми можемо зробити так само подібним.

Наш сайт базується на Laravel з сервером Node.JS в режимі реального часу. Ми використовуємо Laravel Forge.

Хтось має пропозиції щодо того, як ми можемо частіше натискати оновлення? Ми відкриті для чого завгодно.


Чому розгортання займає так довго?
Майкл Хемптон

@MichaelHampton Наші розробки не займають багато часу, ми просто не можемо дозволити собі простої, якщо щось піде не так.
сир5505

1
Я здогадуюсь, питання таке: чому відкат займає так довго?
Майкл Хемптон

@MichaelHampton ми неправильно не розглядали відкати, однак часом ми робимо великі оновлення, які занадто довго знімуть сайт.
сир5505

5
Що б не зайняло великі блоки часу, саме на це потрібно звернути увагу.
Майкл Хемптон

Відповіді:


22

Ви можете багато чого зробити, щоб покращити процес розгортання. Кілька з них:

  • Переконайтесь, що ваш код добре перевірений.

    В ідеалі ви повинні мати 100% тестового покриття, а також інтеграційне тестування для кожного можливого сценарію.

    Якщо у вас цього немає, ви, ймовірно, повинні кинути все і взятися за це.

    Подивіться на розвиток поведінки.

    Наявність повного тестового набору дозволить вам ...

  • Запустити безперервну інтеграцію.

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

    У разі виникнення проблеми CI може також отримати відкат у один клік.

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

  • Зробіть атомні оновлення.

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

    Також вивчіть, чи можуть вам допомогти такі контейнери, як Docker.

  • Зробіть менші, частіші зміни.

    Незалежно від того, чи є у вас тести, CI чи нічого, це одне лише може вам суттєво допомогти. Кожна зміна повинна мати власну гітку git, а розгортання має мати якомога менше змін. Оскільки зміни є меншими, можливо менше під час розгортання потенційно помилитися.

    З цього приводу вносите зміни, коли це можливо, більш ізольованими. Якщо ви внесли зміни в гру Омаха, і це не впливає на Texas Hold'em, 5 карт-коду чи щось інше, то це єдина гра, яку потрібно призупинити для обслуговування.

  • Проаналізуйте що-небудь тривале.

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

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

  • Робота непарних годин.

    Ви, можливо, вже займаєтесь цим, але це згадує. Від розробників (і sysadmins!) Більше не слід очікувати, що вони працюватимуть "9 на 5", особливо для операцій 24x7. Якщо очікується, що хтось проводить години ночі, переглядаючи розгортання, виправляючи будь-які проблеми, а потім дотримуйтесь розкладу дня, ваші очікування нереальні, і ви налаштовуєте цю людину на вигорання.


Найпростішим рішенням тут є використання сценаріїв розгортання в такому інструменті, як Capistrano, і, можливо, навіть балансування навантаження.
JakeGould

Дякую за пораду. Ми розглянемо це. На даний момент у нас взагалі немає тестового набору, і я дуже хотів би розглянути його, проте сайт розробляється вже більше 8 місяців і настільки великий, що на його виготовлення знадобиться більше тижня. У нас працює Laravel Forge, який просто посилається на нову версію до папки, для якої створено nginx. Я не в змозі працювати в непарні години через школу, те ж саме і для інших розробників.
сир5505

1
@ cheese5505 Я знаю, що це засмучує, і це не вирішує вашу проблему, але коли ви говорите це, «… настільки великий, що на його виготовлення знадобиться більше тижня». Це здається безглуздо смішним. Будь-який розумний процес розробки та розгортання дозволить створити сервер менше ніж за день або, можливо, за кілька годин до години. Вам слід справді переглянути, що ви зробили, щоб створити цю купу некерованих речей, щоб цього уникнути. Проблема полягає не в складності, а в основному передбачуваності планування.
JakeGould

1
"На даний момент у нас взагалі немає тестового набору" - виправте це зараз , перш ніж розробляти нові функції. Це ваша найбільша больова точка і буде ризиком доступності. Автоматизоване тестування пройде довгий шлях до запобігання перебоїв у роботі та значно зменшить біль у роботі.
Джош

6

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

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

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


Коли ви відрізняєте бекенд від фронтенду, ви маєте на увазі повністю модульну архітектуру програмного забезпечення? Або архітектура сервера, така як балансир навантаження?
JakeGould

2
просто те, що приймає з'єднання та доставляє їх до поточного основного сервера.
user9517 підтримуєтьсяGoFundMonica

5

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

Це допомагає наступним чином:

  1. Серйозні проблеми завжди зустрічаються з нульовим простоєм.
  2. Перехід на нову версію має рівно нульовий час простою, оскільки нова версія вже запущена та прогріта.
  3. Ви можете будь-коли перейти на стару версію, оскільки вона все ще працює фізично.

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


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

1
Головне - просто переключити балансир навантаження на перевірену робочу версію. З цією поточною моделлю у вас цього немає.
usr

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

@PeterGreen Веб-сайтам дуже важко бути державним, оскільки це не дозволяє кластеризувати, і стан може бути втрачено в будь-який час при переустановці / перезавантаженні / збої / bluescreen і т. Д. Тому це дуже рідко.
usr

@usr Більшість веб-сайтів мають стан. Цей стан може зберігатися або у файлах, або в базі даних. В останньому випадку база даних може бути локальною або віддаленою. Деякі оновлення, ймовірно, матимуть вплив на цей стан, тобто оновлення та відкат не такі прості, як просто перемикання коду.
Пітер Грін

3

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


2

Щоб додати до попередніх відповідей:

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

  • Використовуйте повне управління конфігурацією, не залишайте нічого керованого вручну. Приклади таких систем, як SaltStack, Ansible та Puppet. Вони також можуть бути застосовані до конфігурацій контейнерів Docker і бродячих коробок.

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

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

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

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


0

Я погоджуюсь із Майклом з усіх його пунктів ( /server//a/739449/309477 ).

На мою думку, перше вдосконалення, яке ви повинні зробити, - це використання інструменту розгортання (Capistrano).

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

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

По-друге, якщо гроші не є вашою основною проблемою, вам слід мати сервер розробки iso-prod, який перевірить вашу програму, перш ніж розгорнути її у виробництві. Використовуйте промислове рішення (Ansible, Chef, Puppet) для управління екземплярами VPS.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.