Just because we are a lean startup doesn't mean we need to run in chaos. I certainly am not going to cast all hard lessons learned in the trash. I know that if a disparate development team is not given a solid and stable platform for code migration, our IT ops will be a mess. My ITIL students and past clients have heard this expression a million times from me. If you want to cleanse the pond, you must clean the streams that feed it. In other words, if you want a clean IT operations platform, you must have solids standards and architectures in place for all involved to work from. Breaking down the DEV/QA/UAT/Prod barriers is a challenge. Typically it is based on rights and security. Access control can be a nightmare and causes much of this angst. By setting up boundaries and protocols up-front, the streams will stay clean and the pond will be a source of value.
So here is my strategy straight out of SMAKs operation guide on how I plan to allow autonomy and control co-exist.
User Setup and Configuration:
To secure the environment we will utilize a strategy of layered access to systems. Each environment will utilize the same set of layers with a name denoting their environment.
To gain physical access to systems (keyboard, SSH, Remote windows) there will be a user created.Once physical access is gained you will need to change user or run-as a user with rights to access either system settings / application data (php, xml files / database settings / database information.
Access controls are organized in to functional groups based on assetts. Asset types fall into 5 categories:
Production – Production environment with real users and customers. Needs to exhibit high service warranty.
Demo – Production+ build version of our site with fake data that we will use for demonstration at events, webinars, and other marketing events. (Production+ means at least production vesion with potentially new features to demonstrate functionality)
UAT – User Acceptance Testing Environment– QA Build version signed off on by production release team for Security; Availability; Performance testing. Now awaiting user interaction; regression; usability and design; product marketing sign off.
QA – Quality Assurance Environment – Build version that has been signed off by development team and gone through integration testing. Testing in this environment will focus on Functionality; Security; Performance; Availability; Installation; Recovery. Training to production release team will happen at this build stage. Sign off by Product Management.
Dev – Development Environment – Dynamic build versions be created in this environment with 2 core focus areas
- InnoDev - New product development focused on publishing new feature sets and requirements from Product Marketing team.
- ProbDev – Problem Management environment focused on production snapshots for replicating issues found in production.
The following table lists the usernames: {obviously cleansed and changed for security purposes} Key here is to create naming conventions that make it ease for each lifcycle to be identified and controlled. This will make it a lot easier with building RACI models in your CMS map.
| User Type | Production User Name | Demo User Name | UAT User Name | QA User Name | Dev User Name |
| Group Name | |||||
| Enterprise Cloud Administration | |||||
| Access User | |||||
| System Admin | |||||
| Application Administration | |||||
| Database Administration | |||||
| Data Access User (can see datapoint for customer information) | |||||
| Customer Service Access (access to configuration and registration info) |
