Interactive Computing

The Managed Interactive Computing Service (MICS) is a service to sustain and scale a collaborative, community-driven, interactive computing service for communities in research and education.

Attention

Communities Representatives: docs.2i2c.org has the information about how to use 2i2c interactive computing hubs..

• Hub Rollout Process
  • Process Overview
  • Step Guides
• Sales Engineer Guide
  • Your Role
  • What You Need to Do
    • Listen first, then guide
    • Gather key technical context
    • Solve the XY Problem
  • What Success Looks Like
• Needs Assessment Guide
  • Your Role
  • What You Need to Do
    • Confirm and validate requirements
    • Pin down the technical specifics
    • Propose the technical plan
    • Write the GitHub issue
  • What Success Looks Like
• Validation Guide
  • Your Role
  • What You Need to Do
    • Confirm community representatives can log in
    • Verify broader community access
    • Make the call
  • What Success Looks Like
• Onboard a Community
  • Information collected about a community
  • Process to deploy a new hub
• Offboard a Community
• Community Value
  • Engagement - Details
  • Engagement - Summary
  • Time to First Value
• Communicating Changes
  • When this process applies
  • Responsibility
  • How to send this out?
    • Create a CSV
    • Create an email using our template
• Making Changes to Multiple Hubs (network-wide updates)
  • Define the rationale, scope and rollout procedure of the change
  • Schedule the migration
    • How to choose which cluster should go in what batch
  • Complete the migration
  • Communicate with our communities
  • Celebrate and share our success
• Adding an Additional Hub to an Existing Community
  • Purpose
  • When this applies
  • Decision questions
  • Roles and responsibilities
  • Process overview
  • Outputs
  • Example: LEAP additional GPU hub
• Dedicated and Shared clusters for hubs
  • How we approach clusters
  • Policy for new hubs:
  • Policy for existing hubs:
  • Process for migration:
• Budget alerts response
  • What to do when such an alert is triggered
    • Steps
• Showcase Hub
  • Purpose
  • Images and environment
  • Data retention
• Incident Response
  • Things to know before an incident
    • What is an incident
    • When is the incident response process triggered
    • The incident team
      • Roles and responsibilities
      • Accountability
  • Incident response process
    • Incident sources
    • Steps
      • 1. Validate that we are dealing with an outage
      • 2. Officially mark the beginning of the incident
      • 3. Try resolving the issue
      • 4. Get all hands on deck
      • 5. Communicate our status every few hours
      • 6. Make sure the incident is resolved
      • 7. Communicate when the incident is resolved
      • 8. Take follow-up actions
    • Handing off Incident Responder status
  • After the incident
    • 1. Create an Incident Report in PagerDuty
    • 2. Create post-incident action items
      • Responsibility
    • 3. Fill out the Incident Report
      • Report lifecycle
      • Responsibility
      • Steps
      • Tips for writing an incident timeline
    • Key terms
  • Paying out past Incident Report debt
    • Process
      • The "Pay out past incident reporting debt"
        • Handle incident report review
        • Handle incident report writing
        • Archive outage-related Slack channels
      • The "Review past outage resolution and actions"
        • Handle action items and incident resolution**
        • Publish incident reports**