[Cadre-politics] 100 org questions & answers
Dan MacNeil
omacneil at brave.cs.uml.edu
Mon Jul 10 14:39:37 EDT 2006
Thank you. Your question makes the effort so far worthwhile.
> -At what point will we press UML's bandwidth?
I've dropped an email to an informal contact in telcom asking how much
bandwidth we are using now and if tripling our use would be a problem.
At recent presentations, I learned the university is planning to spend
a few hundred thousand dollars per year to connect to Internet II. My
guess is that increasing our bandwidth use 3 times, won't be a problem.
> At what point will the relatively low reliability
> of UML's connection become an unacceptable liability?
I'm not sure that objective measurement shows the university's network
is unreliable.
In March I did an analysis of our downtime []
[] http://downtime.thecsl.org/analysis.html
From November to March we had uptime of 98%
Causes were approximately:
44% hardware (failed hard drives)
35% University infrastructure (telcom)
20% CSL error (one incident)
The "(telcom)" label above is a bit misleading as most of the downtime
in this period was electricity related.
From March to today, we've had (adding it up in my head) about 20 hours
of downtime and 99% uptime. From my very rough eyeballing a somewhat
greater percentage of the downtime was university infrastructure.
The big chunk of the recent downtime was Easter Sunday which of course
was a big hassle for Gregg and his grant due the next day but not for
many other people.
The summer you were here, the human interface for telcom had enough
rough spots to color our judgment. While things aren't perfect now, (If
the network goes down @ 5:01pm, we can't open a ticket until 9:01am)
they are better, maybe good enough. John Oulette and Marcie Byrd will
take my calls during working hours and are generally responsive.
Do you think we should spend resources on attempting to improve the
human interface?
#######
Josh Harding wrote:
> One item not mentioned in the questions:
> -At what point will we press UML's bandwidth? At what point will the
> relatively low reliability of UML's connection become an unacceptable
> liability?
>
> My personal opinion is that a reliable connection is one of the most
> important infrastructure needs we will have as we expand.
>
> On 7/9/06, Dan MacNeil <omacneil at brave.cs.uml.edu> wrote:
>
>>
>> --------
>> MOVING TO 100 ORGANIZATIONS
>>
>> CAN WE MAINTAIN CONTACT INFO FOR 100 ORGANIZATIONS WITH A SPREADSHEET
>> AND LISTSERV?
>>
>> yes, the slightly tricky part is being sure to update both.
>>
>> Q: WHAT LEVEL OF TECH SKILL ARE WE EXPECTING FROM OUR NEW CUSTOMERS?
>>
>> Probably about the same as the old customers. Some know the difference
>> between a dir and a driver some won't. All will be focused on getting
>> their work done and spending as little time as possible dealing with
>> those pesky computers.
>>
>> WHAT STEPS CAN WE TAKE TO ATTEMPT TO DEAL WITH THIS LEVEL OF SKILL?
>>
>> We can fix some of our obvious usibility problems. Examples:
>>
>> a. /home/sites/utec-lowell/doc_root
>> should be:
>> ~/web/utec-lowell/doc_root
>>
>> b. control panel, control panel, control panel
>>
>> WHAT ARE OTHER GOALS THAT ARE MAYBE BETTER THAN GROWING TO SUPPORT 100
>> ORGANIZATIONS?
>>
>> a. training/development to get good at software improvement
>> b. adding features, (drupel, smtp auth,
>> server side msg filtering calendars)
>>
>> WHAT ARE SUB GOALS OF THE MAIN GOAL?
>> a. bring security to needed levels
>> b. bring usbility to needed levels
>> c. bring relibility to needed levels
>> d. start measuring quality emperically
>> e. ticking system
>> f. control panel
>> --has many sub, sub goals
>>
>> WHY DO WE WANT TO BE AN ISP?
>> a. writing server based software requires understanding servers
>> b. the world should be able to use more than verizon.
>> c. discipline applies to other areas.
>>
>> HOW WILL INCREASING OUR NUMBERS SERVED TEND TO REDUCE THE QUALITY OF OUR
>> SERVICE?
>>
>> It will be harder to do stuff like dealing with register.com for people.
>>
>> DO WE NEED A FULL TIME LEADER TO HANDLE 100 ORGANIZATIONS?
>>
>> No, probably not.
>>
>> WHAT PROJECTS DO WE NEED TO FINISH TO BE READY TO SUPPORT 100
>> ORGANIZATIONS?
>> Wait till next week.
>>
>> A. WHAT NEEDS TO BE DONE TO HANDLE SERVER LOAD?
>> I. MORE HARDWARE ?
>> II. BETTER ARCHITECTURE ?
>>
>> Server load is definately ok for everything
>> but SPAM processing.
>>
>> B. WHAT NEEDS TO BE DONE TO HANDLE TECH SUPPORT LOAD?
>> I. HOW DOES EASE OF USE NEED TO BE IMPROVED?
>> yes, see above.
>>
>> II. HOW DOES TICKETING NEED TO BE IMPROVED?
>> yes, some things are falling through cracks already.
>>
>> III. WHAT TASKS NEED TO BE AUTOMATED?
>> site creation/deletion
>> III. WHAT TASKS NEED TO BE HANDLED BY USERS?
>> email & account creation.
>>
>> C. WHAT NEEDS TO BE DONE TO HANDLE INCREASE IN BILLING ?
>>
>> keep spreadsheet up to date.
>>
>> WHAT NEEDS TO BE DONE TO IMPROVE PERFORMANCE MONITORING?
>> We need to start monitoring the load on the spam filtering boxes.
>>
>> WHAT NEEDS TO BE DONE TO IMPROVE SECURITY?
>> see complete project list. (next week)
>>
>> DO WE NEED TO BE COMPLETELY SCALABLE?
>>
>> no, but it will be very, very tough to change interfaces after
>> this
>> next bump up.
>>
>> WHAT ARE SOME DEADLINES ?
>> Friday August 25, summer workers stop working
>> Friday December 29, new year.
>> Tues May 01, presure to finish stuff for mvhub gets intense.
>>
>> WHERE DO WE DRAW THE LINE BETWEEN TIME AND FEATURES?
>> I don't know if we have enough info to make that decision.
>> We might when we have a draft project list.
>>
>> DO WE NEED TO IMPROVE MEASUREMENT AND EVALUATION?
>> A. RESPONSE TIME?
>> B. DOWNTIME?
>> I. DURATION ?
>> II. CAUSES ?
>> C. CUSTOMER SATISFACTION?
>> D. ABANDONED PROJECTS ?
>>
>> A-C yes, D maybe not
>>
>>
>> WHAT PROJECTS ARE IRRELEVANT TO 100 ORGANIZATION GOAL AND SHOULD BE
>> POSTPONED?
>> hard to say now.
>> maybe logging, cyrus migration
>>
>> DO WE NEED ADDITIONAL INFRASTRUCTURE TO ATTRACT 100 ORGANIZATIONS?
>> A. DO WE NEED A RESELLER INTERFACE?
>> B. DO WE NEED TO OFFER MORE SERVICES THAN WE DO?
>> C. PRECISE CALCULATION OF UPTIME?
>>
>> maybe, but we should worry attracting users after we can support them.
>>
>> WHAT OTHER COMMITMENTS DO WE HAVE THAT WILL TAKE RESOURCES AWAY FROM
>> GOAL?
>> utec
>> day to day tech support
>> lowelldeeds
>>
>>
>> ARE ALL OUR RESOURCES A GOOD FIT FOR THIS GOAL?
>>
>> no, about 1/2 the group has little system admin experience.
>>
>>
>> WHAT PROBLEMS BECOME STATISTICALLY MORE LIKELY BECAUSE WE WILL BE A
>> LARGER TARGET?
>>
>> somebody will install or write an insecure php script.
>>
>>
>> DO WE NEED SMTP AUTH?
>> DO WE NEED TO MONITOR OUR USERS FOR SPAM?
>> DO WE NEED TO MONITOR OUR USERS FOR VIRUSES?
>> probably
>>
>> RIGHT NOW, USERNAMES HAVE TO BE UNIQUE SYSTEM WIDE, DOES THIS NEED TO
>> CHANGE?
>>
>> yes. Perdition seems like a way for this to work.
>> http://www.vergenet.net/linux/perdition/perdition_paper/
>>
>> DOES ANYONE CARE ABOUT HAVING A @THECSL.ORG EMAIL ADDRESS FOR PERSONAL
>> USE IN ADDITION TO THEIR @DOMAIN.ORG ADDRESS ?
>>
>> probably not.
>>
>> SHOULD WE AUTOMATICALLY CREATE PERSONAL WEBSPACE FOR PEOPLE WHEN THEY
>> GET AN ORGANIZATIONAL EMAIL ADDRESS?
>>
>> no, we should stop doing this.
>>
>> IF WE CHANGE THE WAY THINGS WORK, DO WE HAVE TO SUPPORT THE EXISTING
>> INTERFACES?
>>
>> yes, for email, no for shell & ftp
>>
>> ARE OUR BACKUP AND RESTORE SYSTEMS ADEQUATE TO HANDLE 100 NEW
>> ORGANIZATIONS?
>>
>> almost, We need to move to virtual servers.
>> we probably need periodic restore drills.
>>
>>
>> _______________________________________________
>> Cadre-politics mailing list
>> Cadre-politics at lists.thecsl.org
>> http://lists.thecsl.org/cgi-bin/mailman/listinfo/cadre-politics
>>
>
More information about the Cadre-politics
mailing list