Personas-SystemEngineer » History » Revision 6
Revision 5 (Kyle Baker, 12/15/2014 03:11 PM) → Revision 6/10 (Kyle Baker, 12/17/2014 12:02 PM)
h1. Samuel, System Engineer, ACME Financial Services Company
h2. “We think of innovative ways to make systems management better for the whole institution.”
|/2.!http://projects.theforeman.org/attachments/download/1050/Samuel.png! |*Daily Katello/Foreman Usage*
6 Hours |*Years of Experience*
7 Years |*Primary Role*
System Architect |
|\3.*Role Description*
My role is the server build architect. I work on developing build procedures and automation. I decide what packages, errata ( security, enhancement) are deployed. I also am responsible for system resources, including bare metal, virtual, and cloud. I also handle all entitlement management of the Linux systems. I manage all OS based decisions and application usage across the entire institution.|
h2. Linux Build Process
h2. What is a typical day at work?
Usually login and check they systems, clone channels, check critical errata list. Reviews what systems are not patched yet and what the status is on any currently running tasks. We have written our own script to show how many systems are compliant/non-compliant, which are in a critical state. Troubleshoot defects because of deployment issues
My team works with the project teams (managed organizations) to engineer solutions and meet needs/requirements. We use our scripts or manually architect new builds which we test in our labs. We are tasked with the upkeep of our labs testing machines. We then package the new system template that we make available to our administrators.
We often will evaluate new technologies and suitability.
h2. How are the responsibilities divided on your team?
Our team operates as one though we have different disciplines. My coworker and I are linux specialists. One member is a windows engineer. We have a teammate which is a specialist that is focused on data centers around the globe (security and physical/locale details). They work with security teams which is a totally different department. Networking operates the same way.
We all interface with operations teams: these 3 groups are responsible for managing their systems.
We also have a few project managers and analysts which keep an eye on software being deployed company wide.
h2. How do you use Katello/Foreman in your environment?
We set up and maintain the Katello/Foreman server. We map the tool to our infrastructure and modify it as our environment grows. We oversee all systems management across organizations.
When new software is released we define builds in the form of requirements/standards. We then present them to stakeholders. We then use the Katello/Foreman workflows process to build a deployable kickstart file. This file is used by the system administrator to stand up a machine.
We also rely heavily on the life cycle management capabilities of Katello/Foreman. Our primary task in this role is to develop/ maintain/ promote new packages. These packages will be turned into builds and be spread across our infrastructure.
In the future we will manage all linux based cloud deployments with Katello/Foreman.
h2. What is your biggest challenges?
*Workflow Gaps*
We have to guide System Administrators through the complete systems deployment process. They don’t use puppet or know what it is. The benefit of complete Katello/Foreman product is limited for them. They don’t need the entire workflow around of lifecycle environment - they have internal infrastructure for that. For them license management is Katello/Foreman main use. Another UI may meet their needs better. What they need is a UI that is good for administrators who like point and click. Katello/Foreman makes sense in areas where you start from scratch, but they already have several configurations already set up. They need synchronization and license management, repository management, notification and the option to deploy a license from central user interface.
*Trouble Shooting*
We often have difficulty in trouble shooting the systems. With a 10k+ system inventory it takes them awhile to get to root cause. if packages are loaded from different depots that cause problems we have to do work to see why updates have failed/stopped. We end up troubleshooting for quite a bit to find a simple problem which should be obvious.
*Evangelization*
Part of our job is to sell everyone across the company on new technologies. When a technology has workflow gaps it makes it difficult to sell.
*Subscription Management*
The procurement group responsible for purchasing subscriptions is a separate department. Purchasing or renewing subscriptions is difficult when there is little reporting causing the process to be manual. Also having more than one entitlement per machine makes it even harder to manage.