**Mastery Loadouts**
Due to issues related to the release of Mastery Loadouts, the "free swap" period will be extended.
The new end date will be May 1st.
Due to issues related to the release of Mastery Loadouts, the "free swap" period will be extended.
The new end date will be May 1st.
Scheduled maintenance affecting AQ
Woody141082
Posts: 225 ★★
Hey kabam is there anyway we can get scheduled maintenance done on the 3 days where there isn’t AQ running? Or at least set AQ to 30min timers on the days it is running. Maintenance went over the allotted time last night and not only has it screwed my alliance up running map 6, you can’t expect everyone to be able to stay up way past their sleep times to be able to continue moving. Maintenance is usually set at 1-2 hours, this isn’t a problem, but when it’s running past 3hrs it starts to become one. It seems certain timezones don’t see no affect to this but it seriously affects other timezone users. I dread to think what the alliances running map 7 had to put up with. Can we get some feedback on this?
0
Comments
The why of it has been covered in past discussion threads, but they revolve around facts operations people would know and non-operations people often try to argue against the reality of. Some days are bad: weekends, Mondays, and Fridays are generally bad for maintenance downtime in lots of cases. Most organizations aware of this schedule maintenance windows on Tuesday, Wednesday, or Thursday as a result. Tuesday is the hands-down favorite. Moving the schedule around is also bad: in practice having all the moving pieces get into a rhythm when it comes to maintenance windows and then changing it increases the likelihood of something going wrong.
So you'd only do this when the benefits are overwhelmingly high. And moving downtime around to match the AQ schedule doesn't have a sufficiently high benefit. In the general case AQ and AW are on different schedules so trying to accommodate AQ would simply cause collisions with AW: you can't avoid both. There's no obvious preference between disrupting AQ and AW. And individual people's schedules are all different, so downtime affects or doesn't affect different people in different ways. So there's no universally good or bad time, or revolving schedule.
With enormous upside to using fixed maintenance windows on a day like Tuesday, and no overwhelming benefit to doing anything different from that, here's where we end up.
A related subject is that Kabam is almost certainly structured into an operational group and a development group and generally speaking the developers don't have direct control over the live servers, the operational group does. So when Kabam developers make an update for the game, say, they can't just log into the servers and load that update. There's a process where the update gets packaged and sent to the operations people who themselves have the authorization to log into things and apply updates.
There's two reasons why you do this (well, at least two). First, you don't want developers to be able to touch live servers, because we all know what happens when you do that. It is far too irresistible for a dev to log in directly to a live server and make "one little change." Yeah, no. And second, you want some distance between the people who really understand how the game works at all levels and the people who can tamper with it directly. You don't want developers with operator privileges to be abusing them to hand friends stuff. Operators understand how to keep the machine running, but don't necessarily understand how to alter the game itself in that way, which is a useful Chinese wall.
So when thinking about how maintenance and downtime work, keep in mind the people who understand the changes often aren't making them, and the people making them often have no idea what the changes will do. So things have to happen in a very well organized and regulated way. The developers themselves don't even "own" the servers in the sense that they have any control over them at all in most online game companies like this (in fact, unless you self-publish it is often the case that the developers and the operators are two completely independent companies that don't directly work with each other).