< back

Source

Description

The sourceSource service will be implemented using a software package named gitlab. This product allows for collaboration between multiple contributors on code repositories. Additionally it provides a web interface to make interacting with git more enjoyable. Finally, there are integrations with this service that will allow us to utilize the WSU Active Directory infrastructure.

Availability

  • This is an internally consumed service of the CIT group.

Life cycle

  • OS Patching - This server will be included in the monthly patching cycle performed by the CIT Server Team.
  • Application patching - The patching of this service will be integrated with the OS patching cycle due to integration with the YUM package manager. If there is need for an out of band upgrade that can be requested through the change request process.
  • If the production VM environment is deprecated this service will be archived to Cloud for possible future retrieval.
  • If this service is determined to not be of use any more the repositories will be archived independently to Cloud for future retrieval.
  • The usage of this service should be re-evaluated every two years. (July 2018)

Dependencies

  • This service is dependent on:
    • Production VM infrastructure
    • Central ITS AD infrastructure
    • Central ITS Network infrastructure
  • Services dependent on this service:

Workflows

Service requests

  • Operational requests that should be able to be completed by anyone with access rights
  • Easy and quick
  • Completed in under an hour
  • Should occur relatively often
  • How should some one enter a service request

Change requests

  • Out of cycle upgrade -
  • Significant changes to the service
  • May require SME level knowledge
  • Long time to completion
  • May require restricted priviledges

Uptime

  • This service will be available during extended business hours (M-F 7AM - 6PM).

Maintenance

Announcements

  • Any maintenance will be coordinated within the CIT group during normal business meetings
  • HowIf willthere we go about notifying users of the service about routine maintenance (e.x. we will notify users of any outage 48 hours in advance)
  • Outage communications (e.x. we will send outis an outage notificationof withinthis 1 hour ofservice the startuser of an outage, Additionally our monitoringbase will automaticallybe updatenotified our status page.)verbally

Update policy

  • Not sure what I meantwill byyell this as it was covered indown the lifehall cycleevery section.hour.

SLA

  • TimeService requests: 8 normal business hours
  • Change requests: Responded to resolution on service request and change request (e.x. We will triage all requests with inestimate 1within hour. All standard service request will be processed in under 8 business16 hours
  • Service survivability and recovery
    • Service survivability
      • How precarious is this service
      • e.x. TheThis service is basedprovided outfrom ofthe Hulbert facility on the Pullman Campus in the Primary data center facility.Campus. If there is any disruptionproblem towith the network, building, or campus this facility then the service will be unavailable.
      • e.x. The service is based on a distributed architecture with intelligent load balancing technology to allow for significant outages without causing an outage.disrupted.
    • Service Recovery
      • If the underlying services are not able to be repaired what is the recovery plan.
      • e.x. We will reimplementrecover the service using off-premise equipmentrepositories and retrievemove datathem fromto ouranother backup solutionprovider.
  • How will this service be monitored
    • What steps will be taken to assure the SLA and other items in this documentation.
    • e.x. We will useperform UptimeRobotbasic andup/down Bosonmonitoring tousing monitorUptime healthrobot metricson originating22, from80, the underlying equipment to provide real-time information to our alerting systems.443.

Data access policy

  • Under what circumstances can CIT lookhas atthe thisright data
  • to e.x. CIT will not accessreview any data belongingcontained toin customersthis service without explicit permission from the data/service owner. This may delay troubleshooting activities while permission is sought. CIT is allowed to access and review metadata about the data/service to try and aid in rapid recovery. If there is a case not covered here the decision will fall in favour of the data owner.notification.

Data stewardship

  • Back up
    • What will we do for backups?
    • e.x. We will useutilize ourthe standardcloud backupdata systemstorage offering to takeback systemup leveldata backupsfor ofthe service. This will be implemented in the underlying OS.
    • e.x. We will backup the code repositories and database independently on a daily basis. This will allow us the ability to reconstitute the service on another platform within 4 hours.OS
  • Retention
    • How long will we keep the data?
    • e.x. We will utilizekeep ourdaily standardbackups backupfor schedule.a Youweek canand referthen toweekly insertbackups linkfor herea to find out our backup standards.month.
  • Survivability
    • What is the survivability of our data backup.
    • e.x. Please refer to insert link here for our data survivability standards
    • e.x. We will utilize ourthe offinherent campus backup facility for this service. This will allow for data survivabilitysyncing in the casecloud ofservice to move the lossdata ofto theour Pullmanoff-site campus.location.

Appropriate use policy

  • What is appropriate use of this service? What is not?
  • e.x. This service is meant to be used according to standard practicesbest and should not be viewed as a space to do a horrible thing that no one in their right mind would ever want to do.
  • e.x. Don’t put 10 TB of incompressible bin files in gitlab practices.

Budget

  • TCA
    • TryImplementation:
      to24 understandhours what- theServer costsetup, application deployment, AD integration, Setup of this service may be. It would be appropriate to use an excel spreadsheet to help with this. backups
    • YouRunning shouldcosts:
      take1 intohour/month account- theApplication wholeand lifecycleOS ofupdates the
      service48 fromhours/2 standupyears - Reimplementation and migration to completenew removal and archival of the data. You can say that this will be reimplemented using current best practices.OS.
    • DoDe-provisioning:
      try24 tohours account- forExport thedata followingand phasesmake ofavailable theon life cycle: implementation, running cost, de-provisioning.Cloud.
  • Recovery
    • Will the cost of thisThis service beis ableexpected to be recovered.consumed Thison shouldan beinternal reconsideredbasis ifand thereas such is evernot asubject change in scope of the service offering.
    • e.x. We will recover theto cost of service via a per repository charge of $x. This will provide for ongoing maintenance and expansion of required equipment.recovery.

Related