Matt of standalone-sysadmin fame asked:
For things that will require disruptive downtime for critical systems that'll exceed a few hours, we keep those to the times we're not teaching. We have on the order of 21,000 actual students kicking around (the FTE count is much smaller, we have a lot of part-timers) so outages get noticed. We have students actively printing and handing in homework to Blackboard at 4am, so 'dark of night' is only good for so many things.
The biggest is the summer intersession, which this year is between 8/25 @ Noon (the point grades are due from faculty) to roughly 9/18 (when students start moving into the dorms), is reserved for the big and disruptive projects. Things like completely migrating every file we have to new hardware, upgrading the ERP system we use (SCT Bannder), replacing the router core, upgrading our SAN-based disk-arrays, or upgrading Blackboard. Winter break and Spring break are the other times during the year when this kind of activity can take place.
Winter has a couple weeks to work with, but we're generally rather short-staffed during that period so we try not to do big stuff. Spring is just a few days, so things like a quick point-level upgrade to Blackboard could be done, something that doesn't require extensive testing, validation, or data conversion. Summer intersession is where the big heavy lifting can take place, and we do try and work our various vacations around this particular time of the year.
But we can and do roll new stuff out during session. If the new thing isn't disruptive to established work-flow it is a lot easier, or it just adds functionality to something they're already using. Anything student-visible gets extra scruiteny, as the potential for massive amounts of work on the part of our helpdesk is a lot higher. A lot of our decisions have significant inputs from the, "How much extra work will our Helpdesk experience as a result of this change?" question.
Also, the work varies. Some years we have a lot going on in the summer. This year we only have the one major project. In years when we have a lot going on, we've started planning the summer project season as early as March. Some things, like the router core update and the Banner updates, are known about 18 months or more in advance due to budgeting requirements. Other things, like Blackboard updates and oddly enough this Novell -> Windows migration project, aren't really committed to until May or later.
As for determining when what gets updated/upgraded, that's the responsibility of the maintainers of that application, infrastructure, or hardware to start. Due to the budget cycle, big ticket items are generally known about very far in advance of the actual project implementation stage. Everything eventually falls into the project coordination sphere, which is a very large part of the Technical Services Manager's job (you too can be my new boss! But wouldn't THAT be awkward?) . The TS Manager coordinates with the Academic Computing director and the Administrative Computing director, as well as the Vice Provost of course, to mutually set priorities and allocate resources.
p.s.: The Technical Services page for Organization Size is horribly horribly wrong. We have more servers then that for both MS and Linux. We have less NetWare servers, and by now less Unix servers. And way more disk space then that.
I take it from the terminology ("fall quarter") that you work at a university.Until a couple weeks ago, this blog was hosted on a server named, "myweb.facstaff.wwu.edu," which should give you a real good idea of where I work ;). So yes, a university. We're also on quarters, not semesters, so our school year is a bit different than those that have only three terms a year instead of four.
How often do you re-engineer your infrastructure, or roll out new servers? Do yo align them to the school quarters? I'm interested in knowing how other people make decisions on roll-outs.
For things that will require disruptive downtime for critical systems that'll exceed a few hours, we keep those to the times we're not teaching. We have on the order of 21,000 actual students kicking around (the FTE count is much smaller, we have a lot of part-timers) so outages get noticed. We have students actively printing and handing in homework to Blackboard at 4am, so 'dark of night' is only good for so many things.
The biggest is the summer intersession, which this year is between 8/25 @ Noon (the point grades are due from faculty) to roughly 9/18 (when students start moving into the dorms), is reserved for the big and disruptive projects. Things like completely migrating every file we have to new hardware, upgrading the ERP system we use (SCT Bannder), replacing the router core, upgrading our SAN-based disk-arrays, or upgrading Blackboard. Winter break and Spring break are the other times during the year when this kind of activity can take place.
Winter has a couple weeks to work with, but we're generally rather short-staffed during that period so we try not to do big stuff. Spring is just a few days, so things like a quick point-level upgrade to Blackboard could be done, something that doesn't require extensive testing, validation, or data conversion. Summer intersession is where the big heavy lifting can take place, and we do try and work our various vacations around this particular time of the year.
But we can and do roll new stuff out during session. If the new thing isn't disruptive to established work-flow it is a lot easier, or it just adds functionality to something they're already using. Anything student-visible gets extra scruiteny, as the potential for massive amounts of work on the part of our helpdesk is a lot higher. A lot of our decisions have significant inputs from the, "How much extra work will our Helpdesk experience as a result of this change?" question.
Also, the work varies. Some years we have a lot going on in the summer. This year we only have the one major project. In years when we have a lot going on, we've started planning the summer project season as early as March. Some things, like the router core update and the Banner updates, are known about 18 months or more in advance due to budgeting requirements. Other things, like Blackboard updates and oddly enough this Novell -> Windows migration project, aren't really committed to until May or later.
As for determining when what gets updated/upgraded, that's the responsibility of the maintainers of that application, infrastructure, or hardware to start. Due to the budget cycle, big ticket items are generally known about very far in advance of the actual project implementation stage. Everything eventually falls into the project coordination sphere, which is a very large part of the Technical Services Manager's job (you too can be my new boss! But wouldn't THAT be awkward?) . The TS Manager coordinates with the Academic Computing director and the Administrative Computing director, as well as the Vice Provost of course, to mutually set priorities and allocate resources.
p.s.: The Technical Services page for Organization Size is horribly horribly wrong. We have more servers then that for both MS and Linux. We have less NetWare servers, and by now less Unix servers. And way more disk space then that.