Download
1 / 42
420 likes | 678 Views
MSF Deployment Phase. MSF Deployment Phase Tasks. Starting the deployment Going Live Stabilizing the deployment Transferring ownership to operations Closing the deploying phase. Starting the deployment.
E N D
MSF Deployment Phase Tasks • Starting the deployment • Going Live • Stabilizing the deployment • Transferring ownership to operations • Closing the deploying phase
Starting the deployment • Starts after a live pilot, where the team uses the equipment, software, and components inventory, schedule, and information concepts that it will use once the site is active. • Team incorporates the information it learns from the pilot into the deploying tasks, ensuring that all known issues have been considered. • Once development is complete, the team will review and update the deployment plan, using information learned during the testing cycles. • Prior to going live, the team should review and step through all recommended procedures, pilot test results, and reports, checklists, or collateral that were provided during the earlier phases.
Going Live • At this point, the pilot has been tested and the team and key stakeholders have agreed on the acceptance criteria. • Acceptance criteria might mandate that all issues have been resolved, or that the solution is ready for deployment with the knowledge that some issues might exist and will be resolved in later versions. • The team should review the checklists for potential issues, and if all appears to working properly, it is time to go live.
Going Live Tasks • Transitioning to Deployment • Deploying the Site • Architectural Considerations Checklists • Other Considerations Checklists
Transitioning to Deployment – Logistic Manager Checklist • The deployment strategy is reviewed and approved. • Setup, installation, configuration, test, and operation and support procedures are available, reviewed, and approved. • Deployment procedures are documented, reviewed, and approved. • Hardware and software components are available and tested. • The deployment team has clearly defined roles, and the assigned personnel are trained and available. • The project schedule has been reviewed and approved. • There is a plan and ample resources for ownership transfer to the operations team.
Transitioning to Deployment Considerations • It is vital that the project team continues to monitor the site after deployment until the transfer of ownership is finalized; This allows the team to establish baseline performance records to determine whether performance is going up or down. • Neither testing nor live pilots can completely reproduce the type of use and amount of load that the servers will experience after going live. • If the stress and capacity tests are performed well, the team should have both test scripts and test results available providing the baselines. • It is important to compare the baseline numbers to the new numbers any time a change is made to the servers, visualizing what effects the change has on performance. • Monitoring will continue on a regular basis, even after ownership is transferred to operations.
Deploying The Sight • The team makes the decision to deploy only after reviewing the test results and information gained by using checklists. • Reviewing the checklists will alert the team to any issues that may influence the deployment. • If your team finds itself investigating the how and why behind a specific consideration, it probably indicates that the project is not ready to move forward.
Architectural Considerations Checklists • Database Tier Considerations • Application and Business Layer Considerations • Presentation Layer Considerations
Overall Considerations • General Technical Considerations • General Business Considerations
Stabilizing the Deployment • A joint venture between the project and the operations teams. • Usually begins in the later part of the developing phase and continues throughout the deploying phase. • Important to include time in the master schedule for stabilizing because it gives both teams an opportunity to fine-tune the solution, resolves any issues that might arise, monitors the site to ensure it continues to work properly after going live, and assists the operations team after the transfer of ownership.
Transferring Ownership to Operations • Transferring the Site • Project Team Tasks • Operations Tasks • Maintaining the Solution • Site Content Changes • Daily Site Management • Upgrading the Site • Microsoft Operations Framework
Transferring the Site • The project team will be closing any open issues and handing off maintenance activities to the operations team. • The operations team will be opening procedures and validating all collateral and equipment received from the project team.
Project Team Tasks • Verifying that the operations team has the proper resources to maintain and manage the new site. • Confirming that the knowledge base for transfer to the operations team is finalized. • Reviewing operations’ logbooks and ensuring that the procedures are being properly performed; The developer should clarify and correct any irregularities that were logged, and ensure that these activities are being maintained and monitored on a daily basis. • Confirming that all project sign-off affidavits are correct.
Operations Tasks • Activate all reporting systems. • Validate and publish all collateral. • Validate and publish the knowledge and databases. • Review training materials provided by the project team.
Maintaining the Solution • Important that operations personnel monitor the site on a continual basis. • Allows the team to remain proactive, avoiding issues before they occur. • Most important aspect of the team’s job is to ensure that the site’s business-critical environment is available seven days per week, 24 hours per day.
Site Content Changes • Operations team manages and maintains site content on a daily basis. • Several tools are available to track and upgrade the site’s content.
Daily Site Management • Testing all system changes, including service packs, newly tested drivers, or newer versions of hardware and software as they are introduced to the environment. • Confirming that the solution’s capacity is monitored on a daily basis, and installing additional boxes if they are required. • Reviewing critical diagnostic messages as they are identified. The team will provide immediate relief to any critical error messages. • Monitoring the system’s recoverability. Should something fail, the team may use third-party tools to identify and correct these issues. • Validating data integrity on a daily basis; this will make sure nothing is corrupted because of memory or program failures. • Implementing daily checks on the site, making sure it responds properly.
Daily Site Management (Continued) • Determining and logging any issues that occur on a daily basis. • Ensuring appropriately controlled release and change management, and accurate inventory tracking of all IT services and systems. • Managing physical environments and infrastructure tools, balancing cost with technology and business needs. • Ensuring quality customer support, quick problem resolution, and dedicated ownership of service level management. • Ensuring predictable, repeatable, and automated day-to-day system management. • Ensuring careful protection of corporate assets by controlled authorization to systems and information. • Ensuring dedicated management of external support and services provided through partners and outsource vendors.
Upgrading the Site • If the site needs extensive add-in information or if the architecture or design needs upgrading, the product planning or marketing personnel might choose to initiate a new or second version project. • No matter how the initial project was deployed, the second version would be deployed by establishing a development, testing, and staging environment that is transferred to production after successful testing and initiating a live pilot. • Although it is possible to manually install the operating system on the servers, using a cloning process like Sysprep.exe is an easy and efficient way to deploy the operating systems on new servers.
Microsoft Operations Framework • MOF recognizes that current industry best practice for IT service management has been well documented within the Central Computer and Telecommunications Agency’s (CCTA) IT Infrastructure Library (ITIL). • MOF combines these collaborative industry standards with specific guidelines for using Microsoft products and technologies. • MOF also extends ITIL code of practice to support distributed IT environments and current industry trends, such as application hosting and Web-based transactional and e-commerce systems. • MOF embraces the concept of IT operations providing business-focused service solutions through the use of well-defined service management functions, which provide consistent policies, procedures, standards, and best practices that can be applied across the entire suite of service solutions found in today’s IT environments.
Closing the Deployment Phase • Signing Off on the Project • Obtaining Customer Sign-off • Producing the Closeout Report • Conducting the Project Review
Signing off on the Project • Once all the deploying tasks are complete, the team must formally agree that the project has reached the deployment complete milestone and that the project’s work is finished. • By approving the milestone, team members signify that they are satisfied with the work performed in their areas of responsibility.
Obtaining Customer Sign-off • Upon project closure, the product manager obtains the final sign-off from a representative of the customer, signaling approval of the solution and permission for the team to disengage from the project. • Although, at this point, the team is busy informally closing outstanding tasks and wrapping up deployment, the sign-off should be a formal acknowledgement that the project is complete.
Producing the Closeout Report • Final versions of all the major project deliverables (for example, vision/scope document) • User information summary • Project review meeting summary • Sign-off by the team • Sign-off by the customer • Summary of next known steps
Conducting the Project Review • When the project is complete, the team should hold a review meeting to discuss the project and identify what went well, what didn’t go well, what to replicate in future projects, and what to change. • Without assigning blame, team members conduct the project review with the goals of learning from mistakes and improving future projects. • Often called a postmortem, the project review meeting sometimes takes place shortly before the end of the project rather than afterwards, because team members might be required to leave the project before it ends.
