PLANNING FOR A LIVE SERVER

Here are a few important guideline that are ought to be followed if there is any server going live at ArijaSoft:

QA SIDE PLANS FOR QUALIFYING:

1. QA should be able to discuss and deliver a testing plan for any of the software/ component that is meant for testing purpose even before starting of testing.

2. This testing plan should contain for each functionality:

a. The testing scenarios where it is supposed to be tested.

b. A proper logic as to define why functionality will be qualified as working if tested with the given scenarios of testing.

3. This testing plan needs to be reviewed and modified before it is being approved.

4. Once the testing plan is approved, the tester is supposed to test each of the testing cases and properly present the results.

5. Once the test cases have been tested, the report needs to be submitted to the developer for any bug rectification with a back up kept at tester for revalidating.

DEVELOPPER SIDE PLANNING FOR WRITING/DELIVERING FUNCTIONALITY:

1. There are three things that needed to be done while writing a functionality:
1. Validate the data that is received
2. Doing the actual functionality
3. Presenting the results properly
2. In any of the smaller or bigger code the developer writes, these three blocks are to be present to make the code into a production/ qualifying.
3. Have to enable logs for all the dependent functions/ programs. These need to be accessible to the concerned QA and also anyone who is responsible for keeping the program running
4. Have to enable a remote start/stop of the servers if found any discrepancy and if no one is available to manually do the shutdown process.

PLANNING FOR THE EXECUTION OF A LIVE SERVER:

1. The server should be prequalified by QA.

2. Developer has to enable a logging functionality for all the servers running live. In our case: PHP log, APACHE log, SCHEDULER log, mySQL log.

3. The log should present the last 100 lines of log from the time of viewing.

4. Since we have a trigger by SMS functionality already implemented earlier on ArijaMobipay server, this type of functionality can be used to start/ stop the servers remotely by using an SMS

5. Remote stopping of the server needs to be enabled by the developer.

6. Look for the dependencies of the server:

a. What are the transactions it does

b. What will be the effects of it

c. Why is the server kept alive

d. What are the resources used by the server

e. What is the correct location to handle/control server? Can it be started and shut down remotely?

7. Always keep a follow up:

a. The server needs to be checked for its health once in a while either by human intervention or by another program.

b. Proper alerts for each exception and proper handlers are to be written.

c. Server needs to be monitored 24x7 for any failure/ mishap.

8. Use of limited resources:

a. Instead of redirecting the server for main transactions, always redirect it a dummy or testing account where the allotted resource (money) will be limited. This shall reduce the threat for continuous transactions.

b. Never allocate the main account which has all the transaction resources to the live server. Even if it goes to the client side also, always keep the resource limited to the server.

9. Monitor the server:

a. The server should never be left unattended. It should either be shut down or should be monitored by someone. This might call for shift system where the server monitoring is to be divided among two/ three people who will monitor the same for certain period of time everyday.

b. There should be a trigger embedded in the server when there is a heavy/ imbalanced flow of information from the server

c. Always intimate the server support (whoever is monitoring the server) about the present status of the server when leaving charge. The status of server will include :

i. Number of requests to be processed

ii. Any downtime that has occurred.

iii. Settings if any changed.

iv. If any transactions are bound to happen.

10.Only when the above things are done, then the server is allowed to go live

PROCESS:

1) Resource (Monitory):

Always use Limited Monitory resources.

2) First week of Live Server:

Server has to be monitored by 24x7.

Team has to have shifts in managing it.

3) Further days of Live Server:

Check Health scripts need to be written.

Every 1hr scrutiny scripts have to be enabled..

4) A New Script - That can catch all possible mistakes.

Like resending etc

5) DISAGREE_COMMIT –

Always disagree on a particular work/statement/plan if it is different from what we anticipate. Then have a common view on the same which shall have to be agreed by both. Once it is committed, both the parties will be aware of the same. This reduces a lot of communication gap and other burdens.

Blogged with the Flock Browser