SRCF: Further Mechanisation
The SRCF has benefited from a lot of mechanisation. The computer programming maxim, "optimise the critical path", motivated a lot of writing of scripts for doing common tasks. There's doubtless an equivalent dictum in management science, and economics, but the phrase above is the one most likely to be known to SRCF sysadmins.
Nowadays, the SRCF has a large number of administration scripts, which tend to live in /usr/local/sbin. A lot of them even have vaguely useful manpages. These do various common tasks, and where a sysadmin knows which script does the task he/she is attempting to accomplish, it's almost inconceivable that the script won't be used. Their use promotes uniformity, as well as qualitatively reducing the amount of effort involved in administration.
Generally, the actions these scripts perform are requested via email, by users or the Membership Secretary. Whatever the merits of the current division of responsibilities between Sysadmins, Membership Secretaries and users, which could be very different if users were permitted to run some of the scripts directly themselves, the SRCF would benefit from a more rigorous and formal approach to day-to-day administration scripts.
Day-to-day admin scripts and so on cover the following sorts of areas:
- adding and deleting users
- changing relationships between users and groups
- changing the association between users and various resources:
- websites
- email addresses and lists
- SQL databases
- manipulating quotas
To the extent that it's beneficial to have matters under the sort of quick, formal, uniform management of scripts, the sysadmins should have means of ensuring that everything that does so benefit from such management is actually under it.
Working out whether a given process should be under scripted management can be done a priori or a posteriori: people can try to dream up all the examples, or new examples can be spotted as they arise in practice. Historically, it's been a bit of both: the initial admin scripts came in circa April 2000 to complement the introduction of the "canonical membership list", and since then new scripts have been added to cope with sysadmin demand.
Routine and non-routine administration
There should be established a strong, well-defined and well-understood division between routine and non-routine administration.
"routine" should mean that activity which happens frequently and is conducted according to some pre-defined uniform procedure. This doesn't just mean "read the email, check it's kosher, run the script"; some aspects of responding to security incidents can be made routine as well. Particularly, routine need not necessarily mean either regular or frequent.
The more stuff which gets included within the scope of "routine", the easier it is to reduce the cost to sysadmin spare time of running the SRCF. The more efficient routine administration can be made, the lower the cost, too.
When undertaking system administration activity which is non-routine, thought should always be had to whether the activity ought to be made routine in the future, though this should never be permitted to delay response to whatever the task in hand is. After responding to the user, the sysadmin should email the other sysadmins proposing that the recently completed action (e.g., dealing with closing down a website at a user's request) be added to the repertoire of routines. Then the discussion can unfold over "should this really be routinised/formalised?", "can we script this? should we?", etc.
Where "thought should always be had" is stated in the previous paragraph, it's not expected that such a thought will ever take more than a split-second. Just having awareness is enough.
There should be a single document containing a formal enumeration of everything that is regarded as "routine". This would make training new sysadmins much easier. There might also want to be a document detailing stuff which is regarded as inappropriate for ever being routine :) though I can't imagine what might go into that. Such a routine specification might be useful to the Committee and sysadmins for working out whether responsibilities are appropriately allocated between the various organs of the SRCF and its users, or for assisting with the design or maintainance of automation systems (e.g., for seeing that shell accounts are just another resource alongside websites and SQL, in terms of their interaction with the Mem Sec). A generalised look at how the various day-to-day activities of the SRCF interact with users might be useful, motivating new FAQ questions showing users how to request things such as change of society admins.
When various individual sysadminly acts can be more formally viewed as the performance of particular components of a larger body of procedure, it might motivate or facilitate a more beneficial generalised approach to the generation of notification email messages, passwords, FAQ entries, logfile entries and the sysadmin scripts as pieces of software. Getting the "procedure for adding new routine procedures" right might be really useful.
Irrelevant historical note
I concede that this all sounds revoltingly like ISO9000 (or whatever the number is), the hated "documentation of business processes". This standard originated when some American administrator was sent over to Japan after WW2, to help modernise industry. He got the Japanese people in organisations to write down what they did for that organisation, and productivity improved. What really happened was that this triggered reflection and introspection on the part of employees. The ISO standard is a misapprehension and bastardisation of this effect.