• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1839
  • Last Modified:

Acceptance Criteria - handover from Dev to Live environment

Is their a generic "checklist" out there I could use to accept a development machine into a LIVE environment. This is specifically for a solaris 2.6 platform but is not limited to anyone platform.
Also any "change management" tips on existing LIVE environments.
thanks-in-advance, hyphen
0
hyphen
Asked:
hyphen
1 Solution
 
bronwyn_blackCommented:
hyphen,

There might be something out there, but the main points would be:

- Backup/Recovery/Contingency Plan: **VERY VERY important... The need for a tried, tested, regular, comprehensive backup AND recovery cannot be stressed enough in a live enironment. Also, what happens if the machine crashes and burns? Is there a backup server?

- Security: **VERY VERY important... See http://www.sunworld.com/common/security-faq.html for some hints. Aside from the machine itself, an insecure machine could jepordise your entire network

- Stability: Will it fall over when it finally experiences real load?

- Accesability: Can you use it? Can pepole use it?

- Performance: A slow machine won't make any friends

- Ownership: Who owns this machine? Who will take responsiblity for maint and admin?

- Documentation: ...the slicing info and root password is no good in the head of the admin guy if he's slept in

There's probably alot more you need to look at... perhaps some more comments on this site will add to this list.

As for a live environment... it's kinda similar to introducing a new box, except you need to account for any down-time that an update might require (or cause).

Hope this helps.

Cheers,
Bron.
0
 
geotigerCommented:
I had worked in a heavily audited environment before. Any hardware or software added to the system had to be gone through an acceptance test. It is a good discipline.

Besides what Bronwyn had listed (you can easily spend those areas into more items), I think that you need to start with system boot and shutdown procedures; application startup and shutdown; filesystem layout; resource sharing; printing queues; etc.
0
 
ianBCommented:
We have opened up a new Solaris Topic Area.  

To increase the visibility of questions, we moved questions we felt
appropriate to the new Solaris Topic Area where they will be easier for
Solaris experts to find and answer. You may view your question at
http://www.experts-exchange.com/Computers/Operating_Systems/Solaris/ 

If you have any questions about the new topic area you can contact
Community Support by posting a comment at the following URL or by
emailing us at cs@experts-exchange.com.
http://www.experts-exchange.com/Customer_Service/Experts_Exchange/ 

Ian
Community Support @ Experts Exchange

0
 
ishCommented:
At my site, we require allmachines be extensivly documented, and heavily monitored for "chng mgmt".

The first step was to establish a set of baseline configuration requirements for:
account structure
server settings
hardware configurations
system security requirements
system documentation

This could be a rather LONG post :)    once we established these requirements, we got manegment to enforce them on our development team.  Now when we get a machine from them, it comes with everything that we require.  It makes change over a LOT easier.

Bronwyn gave you a good starting point.

As for the change management thing, there is a really good program out there, designed as a security tool called TRIPWIRE, that will monitor the state of system files.... it was meant to catch hackers that have changed a file's data (especially in critical system files) but works well as a monoitoring tool.  We were not content to rely on that ONE tool, and so wrote a script that is cron'd on all 25 Solaris boxes I have called change_wizard.sh  It uses log files to track critical system file sizes, and campares current file to last check.  If it has been change, it shoots an email to me so that I know a file has been changed.

All of our admins have been taught that if you make s system config change, you must send an email to a central address/folder that details:
What system:
What change:
When:
Why:
If it needs to be backed out, how?

If I get a change_wiz message, I check that folder, no note?  we got a problem...  Change management can save you in a multi-admin environment...

Here is a bare wag at what we use for "system books"  Bronwyn was right about what happens when the amdin sleeps in :)

Host Name:
Domain Name:
IP Address:
Cnames:       1)
            2)
MX Hosts:       1)
            2)

Platform:  
Primary Administrator:
      Phone:
Secondary Administrator:
      Phone:
Emergency 24 hour contact:
      Phone:
      Pager:

Operating System:
Peripherals
Name (Type)      SCSI ID      ADPE #      Serial #
                  
Host ID:
RAM:
MAC Address:
Video: Color Video Card (Rack mounted server, No Monitor)
Disks: AVAILABLE DISKS/CDROMS/TAPES:

ID      Vendor      Product      Rev      Serial Number      Capacity
                              
partition map
Partition      Tag      Flag      First Sector      Count      Last Sector      Mount Directory
      
Eeprom:  

df -k
File system      Kbytes      Used      Avail.      Cap.      Mounted on

/etc/vfstab
Deviceto Mount      Deviceto fsck      MountPoint      FSType      FsckPass      Mountat Boot
                              
/etc/mnttab
/etc/auto_master:
/etc/auto_home:
/etc/auto_direct:

Head -15 passwd:

Ifconfig -a:

Routing Table:
Destination      Gateway      Flags      Ref      Use      Interface
                              
/etc/system:
/etc/inetd.conf:
/etc/syslog.conf:
/etc/nsswitch.conf:
/etc/dfs/dfstab:
/etc/hosts.allow:
/etc/hosts.deny:
Patch Diag:
0
 
ishCommented:
I posted a very comprehensive answer here, and perhaps the response or acceptance was lost in the crash on thursday?
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now