This Text will be saved in my computer museum among other basic literature pieces, like "real programmers write in Fortran" Really good reading - thx! Juraj
> -----Ursprüngliche Nachricht----- > Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im > Auftrag von Allen S. Rout > Gesendet: Donnerstag, 29. Dezember 2005 04:57 > An: [email protected] > Betreff: Re: TSM Reporting tools > > >> On Thu, 29 Dec 2005 10:53:49 +1000, Steven Harris > <[EMAIL PROTECTED]> said: > > > > I like your graph, would it be too much to ask for you to > explain your > > charging scheme? That is always a vexed issue particularly > with those > > managers who make unreasonable volume or retention demands, > and giving > > them what they want, but charging them what it really costs for the > > service is a nice stick to be able to beat them with. > > > Not at all; I can hold forth on this at some length. > (shocked, I know you are) > > > Billing is always an exercise in shared fantasy. Pretending > that this is not so will only frustrate you. You have to > start with a set of principles which are politically > acceptable, and then do rigorous math from those principles, > ignoring that they may be insane from an engineering standpoint. > > My organization is (was) a so-called "Auxilliary of the State > of Florida". We were mostly a State agency, but we had > special accounting rules that permitted us to have bank > accounts and retain money across years. This was because, as > a 'data center', we were expected to regularly make purchases > which were far in excess of a given year's budget. We were > also permitted to bill other state agencies for our services, > in real dollars, which we put into banks, and periodically > bought new mainframes. > > My politically-acceptable fantasy principles were as follows: > > + Recover costs > + Recover enough that the service can be prepared for growth Don't > + recover more than that > > What are the costs? We had a director-level employee whose > entire writ was answering that question; the cost evaluation > experience was fascinating and educational, and not a litle > painful. Your organization will have its' own standards for > things like amortization, measuring benefits overhead for > staff time, redistribution of front-office costs, cubage in > the machine room, power and air handling, etc. etc. But we > have ours, and at the end of the day > (koff-months-koff) it came down to a bottom line of our > annualized costs. > > These principles are insane. Most of our computer equipment > is amortized at 4 years. For the library chassis, we're at 8 > and counting. For the CPUs, we're lucky if we make it to 3. > Disk is all over the map, and how do you note that my TSM > disk is often cast-offs from another project? Insane. But > it matches the principles, so soldier on. > > > That was the number I was supposed to recover. Now, how > should I split it up? > I started out taking every measurement I could get TSM to > cough up (and we all know that we can measure it MANY ways) > and trying to assign numbers to them all. This was hideously > complex, and incomprehensible even to the architect. > > I went through several iterations of simplification, and > finally realized that I had the wrong end of it: The metrics > for charging must be easy to measure, but that's only > necessary, not sufficient. The important measures are ones > over which the clients, the end-users, have direct control. > > They don't care about tapes, they don't need to know when I > move from 3590-J to K, or B to E, or to 3592s. And if I bill > them for frational-tapes, then they will be aware when I > change underlying system structure. Ew. > > I ended up with basically two numbers: Transfer, and storage. > Transfer is upload (backup, archive) and download (restore, > retrieve), as measured by the acctlogs. Storage is whatever > Q occ comes up with (or actually a select, but you get the idea). > > > Pleasantly, I'm a pack rat, and retain logs and accounting > logs. Every time I came up with a new set of rates, I could > re-apply them to the last [period] of data. This let me > start twiddling rates, seeing how I could weight billing > towards one or the other. > > I decided that I would start off aiming for total storage > charges to be about equal to total transfer charges; that is, > when I add up a years' bills, about half of it should be in > each category. As time has passed and costs have gone down, > I've nudged one or the other rate, mostly focusing on how I'd > be changing user behavior. If people are keeping too much > stuff around (I had one customer seriously claim they wanted > 40 copies) then the transfer cost goes down instead of the storage. > > > I presented the completed charge algorithm to management, and > it passed muster. I presented it to customers, and they > screamed. We changed the inputs. Less fantasy FTE, > different fantasy purchasing behavior, less theoretical total > cost. This is where I realized I was dealing with a matter > of shared fantasy instead of engineering. > > > We went through several adjustments along these lines, and > ended up with a rate that my customers absolutely love, at > least those of them who have a grasp of the differences > between TSM and running dump against a local tape drive. > From the fact that they love it, I can infer that we're not > charging enough. Oh well, I'm running a University service, > not a business. > > I'll add to the fantasies reflected in my situation that much > of my backup work is in fact not billed, it's "internal". > This is less interesting from a dollars perspective (the Data > Center pays for it one way or another) than from a "poor > feedback" perspective. My internal customers have only me > carping at them to help them understand and control their behavior. > > > - Allen S. Rout > - That'll teach you to ask me to explain something. :) >
